Representing the state of user sessions of client-server interactions is a challenging task, and conventional client-server systems represent state using a variety of software architectures. For example, some systems may save session state in a cookie on the client, while other systems may save the state in a data file on the server or utilize server sessions to track state. Yet other systems may communicate state through the networked resources themselves.
One example of the latter approach is the HATEOAS (Hypermedia as the Engine of Application State) REST (Representational State Transfer) style of software architecture. The REST architecture is a style of software architecture utilized by distributed hypermedia systems, such as the World Wide Web (WWW), that attempts to represent application state over a computer network via linked hypermedia. Software systems that comply with the principles of REST architecture are client-server based, stateless, layered, cacheable, optionally utilize on-demand code, and maintain a unified interface between the clients and servers.
HATEOAS is a constraint of the REST architecture that specifies all interaction between client(s) and server(s) is accomplished through hypermedia dynamically provided by the server(s). In principle, interactions utilizing such an approach may not require an intermediary session state (i.e., state may be completely represented in the hypermedia itself). A typical HATEOAS system is composed of discrete resources (objects), each of which has a consistent address (e.g., Uniform Resource Location “URL”) that can be accessed by a requesting client over a computer network, such as the Internet. Each individual resource also has a consistent representation, which is indicated by a MIME (Multipurpose Internet Mail Extensions) type defined via the HTTP ‘Content-Type’ header for the resource. The representations can be encoded and transmitted between the server and client in any suitable format, such as JSON and XML, for example.
Resources of a typical HATEOAS system are inter-related via relationships that are defined exclusively by links embedded in the data object which is a representation of each resource. In other words, as a HATEOS system is “stateless” in principle, the state of the system is contained in the resources themselves and the links between resources. Each link includes a “REL” field defining the name of the relationship to the other resource and a “HREF” field defining the address (e.g., URL) to the other resource. During client-server interactions, a HATEOAS system provides four actions on resources: GET, POST, PUT, and DELETE.
In practice, the REST HATEOAS architectural style has numerous deficiencies, which the present invention has been conceived to address. For example, in the REST HATEOAS architecture, additional information is included within the HTTP header, thus tying a typical HATEOAS system to the HTTP protocol itself. Such a configuration may therefore render the typical system unusable with protocols other than HTTP. To address this deficiency, the embodiments disclosed herein remove the HTTP protocol and provide the semantics in a more neutral manner, thereby allowing for client-server interaction across a variety of protocols, if desired. Nonetheless, the HTTP protocol may be one of the protocols, among others, used to engage a system in accordance with embodiments of the present disclosure.
A second deficiency of the REST HATEOAS architecture arises once the objects are separated from their HTTP receiver endpoint. Specifically, the objects lose the content type and URL identity, and therefore this information must be provided via other mechanism(s). Thus, the disclosed embodiments embed this information in a data structure, referred to as the “self entity,” of the object itself.
A third deficiency of the REST HATEOAS architecture is that the ‘Content-Type’ headers must transmit two distinct pieces of information: the type of the object and the encoding method. In typical systems, these two pieces of information may be concatenated with a “+” symbol within the HTTP header string. However, this practice obfuscates both pieces of information, and potentially makes processing of incoming requests from clients difficult and/or error-prone. Accordingly, the disclosed embodiments move the MIME type of the object into the above-mentioned self entity, and preserve the ‘Content-Type’ HTTP header for the purpose of expressing the object encoding method, such as JSON, XML, etc.
A fourth deficiency of the REST HATEOAS architecture is that a URL of a resource is a poor identifier in a complex, highly scaled web server implementation. For example, once a client accesses the system on one server, all the links in the representations are typically configured to point to the same server instance, thus “sticking” that client to that server instance. Thus, in practice, a scaled deployment utilizing a pool of servers must rely on a single entry point, such as a server load balancer, that routes request(s) from requesting client(s) to a particular server within the pool of servers. The servers in the pool must know the name of this entry point and construct their URLs to point to this entry point explicitly. Furthermore, the object itself is highly inflexible and breakable as its URL points to a hard server entry point. For example, as the pool of available servers decreases as one or more severs become unavailable, URL reference(s) to the unavailable server(s) are lost. As another example, as the pool of available servers increases, the clients that are stuck to particular server instances may not be able to utilize the additional computing resources, thereby leading to unbalanced server loading.
More importantly, by combining the server location and the URI of the resource together to form the URL, a typical system breaks a central REST tenet, namely, statelessness. The disclosed embodiments address these issues by separating the identity of the object from the server that provided the object. This identity, referred to as the URI, is stored in the above-described “self” entity and can be used to address the same logical resource on one or more other server instances.
As a fifth deficiency, the REST HATEOAS architecture has no concept of the user performing operations, and instead assumes completely anonymous interactions. Such a configuration is woefully impractical in most modern systems (e.g., e-commerce systems) where user authorization and/or authentication are required to consume resources and execute transactions. The disclosed embodiments address this issue by introducing the concept of a “resource operation,” (e.g., action to be performed on a resource) and defining an “authorization server” to determine whether a requesting user is authorized to perform a given resource operation. Accordingly, all resource operations must provide a user identifier indicating the identity of the requesting user. The identity of the user may be an anonymous identifier, a user role identifier, or other identifier which does indicate personally identifiable information. Such a configuration may therefore allow the user to access resources that are dedicated exclusively to the user and/or to access resources that are dedicated to a particular “role” shared by the user and one or more other users.
A sixth deficiency of the REST HATEOAS architecture is that it is difficult to develop systems that utilize servers that communicate asynchronously with runtime executable programs on the client, in a REST HATEOAS compliant manner, since much of the information about the resources being downloaded via HTTP is contained in HTTP headers that are not easily accessible to the runtime executable programs.