Abstract: Embodiments provide systems and methods for a generic representational state transfer (ReST) framework that can be used to communicate with heterogeneous ReST interfaces. On embodiment of a method comprises storing endpoint configurations for heterogeneous ReST interfaces as configurable files consumable by a ReST framework; receiving, by the ReST framework, a request to perform an operation and ReST resource details associated with the request to perform the operation; generating a ReST request, the ReST request including an endpoint URL for a target resource, a Hypertext Transfer Protocol (HTTP) method, and a header; and sending the ReST request to a ReST server. Generating the ReST request can comprise accessing the first endpoint configuration and extract first endpoint configuration data that is applicable to servicing the request to perform the operation, the first endpoint configuration data specifying the header; and mapping the operation to the HTTP method.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.