Follow location handler and selector functionality in a stateless microkernel web server architecture

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. Provisional Patent Application No. 61/584,037, filed Jan. 6, 2012 and entitled ENCODING APPLICATION STATE IN LINKED RESOURCES IN A STATELESS MICROKERNEL WEB SERVER ARCHITECTURE, the entirety of which is hereby incorporated herein by reference for all intents and purposes.

BACKGROUND

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.

SUMMARY

A method of serving a resource to a client via a computer network is provided. The method may include providing a follow location handler logically positioned on a WAN side of an HTTP server in a server computing system, the follow location handler being configured to be executed on a same computing device as the HTTP server, or on a computing device connected via a LAN to the computing device on which the HTTP server is executed. At the follow location handler, the method may further include receiving a POST request from the client via the computer network, the POST request being to post form data to a resource, wherein the resource is a data object, and forwarding the POST request to the HTTP server associated with the resource. At the HTTP server, the method may include receiving the POST request and associated form data, creating a modified data object based upon the form data, generating a link to the modified data object, and returning the link to the follow location handler, for forwarding to the requesting client. At the follow location handler, the method may include intercepting the link to the modified data object from the server and refraining from forwarding the link to the requesting client over the WAN. The method may further include: sending a GET request to the server to retrieve the modified data object via the intercepted link, and, in response, receiving the modified data object. The method may further include forwarding the modified data object to the client, thereby enabling the client to receive the modified data object in response to the POST request, without downloading the link across the WAN to the client and causing the client to traverse the link across the WAN.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> shows a non-limiting example of a resource in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 2</figref> shows a non-limiting example of a HATEOAS microkernel in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a method of serving a resource to a client via a computer network in accordance with one embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a method of operating a stateless microkernel architecture server in accordance with one embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 5</figref> shows the system of <figref idref="DRAWINGS">FIG. 1</figref> comprising a follow location handler in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 6</figref> shows a flowchart illustrating a method of serving a resource from an HTTP server to a client via a computer network in accordance with another embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 7</figref> schematically shows a selector object in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 8</figref> shows an example of a form comprising a plurality of selector control objects in accordance with embodiments of the present disclosure.

DETAILED DESCRIPTION

From the preceding discussion, it will be appreciated that 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 servers. REST systems are “stateless” in that each request from a client to a server contains all information necessary to interpret the request. This approach allows for a particular server to handle a request from a client regardless of whether or not that server has handled previous requests from that client.

In order to meet said constraints, each resource in a HATEOAS system is a network-addressable object accessible via a consistent Uniform Resource Locator (URL), and HATEOAS systems operate on these objects. In other words, the term “resource,” as used herein, refers to a network addressable data object (hereinafter “object”) that encompasses some meaningful concept. Each object includes all information necessary to understand how to interact with the corresponding resource, such as how to provide a “representation” of the resource (e.g., how to visually present the object to a user via a display device) and how to link to/from the resource. Before continuing, it will be understood that an object may “represent” a resource in that the object provides the current state of the resource, and the object may be usable by each requesting client to provide a “representation” of the object that may be dependent upon one or more characteristics of the client. In other words, as will be described in greater detail below, the same object may be usable to provide different “representations” on different clients. Put another way, a resource may be thought of as a software implementation of business logic, an object may be thought of as an encoding of that business logic, and a representation may be thought of as a manifestation of an object at the client device.

As one non-limiting example, an electronic commerce system utilizing the HATEOAS architecture may comprise a “shipping” resource to maintain shipping information, and thus to respond to requests (e.g., resource operations) for the shipping information (e.g., user account shipping information, available shipping methods, etc.). Similarly, the example e-commerce system may further comprise an “inventory” resource to maintain inventory information, a “price” resource to maintain pricing information, and a “cart” resource to maintain an online shopping cart. From this example, it will therefore be appreciated that the information provided by each resource may be related to (e.g., depend on, depend from, etc.) any one or more other resources.

A given resource may be related to one or more other resources defined by links within the object representing the resource. As one simple example, a saleable good resource may link to a current availability resource indicating the availability of a particular saleable good. As will be described in greater detail below, a HATEOAS system according to embodiments of the present disclosure provides a corresponding resource server for one or more resources, where each resource server is configured to maintain the resource and/or respond to external requests for the resource (e.g., provide links).

Continuing with the above example, the link to the cart link may subsequently be acted upon (e.g., upon actuation of a displayed “add to cart” button) in order to add the saleable good to the online shopping cart and/or to otherwise interact with the online shopping cart. In this way, state transitions are defined via the links, and one or more of the links may be acted upon in order to effect one or more of the transitions. Such a configuration therefore satisfies the central pillar of the REST architecture that all possible next-state transitions be defined within an object provided to the client.

In complex systems, e.g., e-commerce systems, factory floor systems, etc., such linking may be unduly burdensome due to the myriad of interconnected and interdependent rules, e.g. business rules, error handling, etc., which are inherent to such systems. This potential shortcoming has restrained widespread adoption of the HATEOAS architecture for typical complex systems. For example, in an e-commerce system, once a particular saleable good is recognized as out of stock, such an event may effect removal of the saleable good from an online shopping cart, provision of a request to reorder the good, changes to a product page, an increase in price to one or more related goods, provision of backorder notifications for pending transactions, and/or one or more other dependent actions. Failure to effect one or more of these dependent actions may lead to an undefined system state and/or may provide an unsatisfactory user experience. For example, if the available inventory of a particular saleable good is depleted without updating one or more affected resources, users of an e-commerce system may place an order for the saleable good without being aware that the item is out of stock.

Accordingly, typical complex systems may utilize non-HATEOAS architectures. These systems may be “exception-driven” or “error-driven” such that branching (e.g., business logic) is implemented upon occurrence of an exception/error. For example, in some embodiments, upon occurrence of an “out of stock” error/exception (e.g., upon trying to checkout with an out-of-stock product), typical systems may have to, for example: determine whether the product should still be orderable (e.g., via backorder), remove the “add to cart” button, remove the page from search results, etc. Such error-handling may be hardcoded into the client software, potentially requiring frequent updates to the client software as business rules are updated. In other embodiments, the “out of stock” error may simply be returned to the user, and the user may thus be expected to manually handle the error accordingly (e.g., remove out of stock items from cart before ordering). However, such a configuration relies heavily on the user, and may therefore provide inaccurate results and/or may otherwise degrade the user experience. As described below, the disclosed embodiments enable a client without knowledge of a complete set of business rules to present all available options to a user in a representation of the object presented to the user, and effect appropriate state transitions upon selection of an option.

It will therefore be appreciated that it may be desirable to “cluster” each of the business rules, decision logic, etc. around a corresponding resource server. In other words, the business rule(s) related to the maintenance of the “current availability” resource (e.g., reordering, out of stock notifications, etc.) may be instantiated within the logic of the “current availability” resource server. Such a configuration may therefore provide, for each resource, a single repository where logic related to the resource may be maintained. Accordingly, update(s) to the business rules, to link(s) between the resources, and or to the visual representations of the resources may potentially be updated on the server without extensive modification the client software. Furthermore, by instantiating such logic within one or more servers, and thus removing the logic from the clients, the described HATEOAS architecture may potentially allow for lighter-weight client(s) as compared to typical systems.

It will be further appreciated that by clustering the logic for a given resource with the corresponding resource server, an improved schema for linking between objects may be realized. As will be discussed in detail below, requests to a HATEOAS server for a particular object may effect collecting of link(s) related to the object and subsequent attaching the link(s) to the object before returning the object to the requesting client. As each resource server is substantially independent (i.e., does not directly interact with a resource of another resource server), it may be possible for each resource server to be queried (e.g., for links associated with a particular object) in parallel and/or for such querying to be substantially order-agnostic. Accordingly, the disclosed embodiments may potentially provide a more resilient and extensible linking schema that is suitable for implementing complex systems. Although an e-commerce system is used herein as an example of a system usable with the described improved HATEOAS REST architecture, it will be appreciated that the architecture may be utilized by any stateful process and/or any data model comprising inter-related information without departing from the scope of the present disclosure.

Turning to <figref idref="DRAWINGS">FIG. 1</figref>, an example of an embodiment of a HATEOAS-based client-server system <b>100</b> including server <b>102</b> configured to execute a HTTP server program <b>104</b> via microkernel <b>106</b> is illustrated. System <b>100</b> further comprises client computing device <b>108</b> configured to communicate with server <b>102</b> via network <b>109</b>. Client computing device <b>108</b> may provide client <b>111</b> (e.g., web browser) so as to facilitate such communication. Client <b>111</b> may be configured, for example, to provide representation <b>110</b> of a data object <b>112</b> (hereinafter “object”). As previously mentioned, the term “representation,” as used herein, refers to a specific presentation (e.g., visual, audio, etc.) of an object. It will be understood that each object may be interpreted and presented according to various features, preferences, etc. of each client <b>111</b>. In other words, a representation of object <b>112</b> other than representation <b>110</b> may be provided by client(s) other than client <b>111</b>.

As described above, typical HATEOAS systems rely upon the HTTP protocol implementation to provide low-level functions. Specifically, the MIME-type (also referred to as ‘Content-type’) component of the HTTP header may be used to define both the representation of the resource and the encoding method. Including additional information within the HTTP header may restrict use of other communication protocol(s), and/or may otherwise negatively affect operation of the system. The typical HATEOAS architecture may therefore not be able to provide the features of an e-commerce system.

Accordingly, it may be desirable to develop an architecture that is protocol-independent, and as such, object <b>112</b> includes a “self” entity <b>114</b> (e.g., data structure) comprising a plurality of characterizing data that may have otherwise been included in the HTTP header in a typical HATEOAS system. The characterizing data may include, but is not limited to, type <b>116</b>, Uniform Resource Identifier “URI” <b>117</b>, HREF <b>118</b>, and max-age <b>120</b>.

Type <b>116</b> provides a name of a data schema and may be used to define one or more characterizing features of object <b>112</b>. As one non-limiting example, type <b>116</b> of a movie object may be a schema such as “application/vnd.imdb.movie” informing client <b>111</b> that the object is a movie. The schema may further indicate to the client what additional field(s), if any, to expect within object <b>112</b>. For example, the “application/vnd.imdb.movie” schema may be defined to have a field called “rating” that describes the rating of the movie. Thus, upon recognizing an object being of the above-described movie object type, the client may access the “rating” field to determine the rating, if desired. In some embodiments, the additional field(s) may be provided within self entity <b>114</b> and/or elsewhere within object <b>112</b>. It will be understood that the schema does not define the kinds of links to expect, which will be discussed in greater detail below, but rather defines feature(s) of the object, such as the zero or more additional field(s) in the particular object.

URI <b>117</b> may identify the resource represented by the object, whereas HREF <b>118</b> may identify the location of the resource. In other words, HREF <b>118</b> may identify how to access the resource identified by URI <b>117</b>. For example, HREF <b>118</b> may comprise a location of server <b>102</b>, URI <b>117</b> of the particular resource, an action to perform on the resource, and/or a protocol to provide such interaction. As one non-limiting example, URI <b>117</b> of a cart-type object of an e-commerce system may be “/store/cart/123,” whereas HREF may be “https://www.mystore.com/store/cart/123.”

Max-age field <b>120</b> indicates a maximum age (e.g., in seconds) from creation/download of object <b>112</b> that client <b>111</b> may display, or otherwise provide, representation <b>110</b> of object <b>112</b>. Once this maximum age is surpassed, client <b>111</b> may be configured to request an updated instance of object <b>112</b> from server <b>102</b> rather than display representation <b>110</b>, which is over the aging limit. For example, if a particular object <b>112</b> includes max-age field <b>120</b> of 86,400 seconds (i.e., 24 hours), client <b>111</b> may use this information to cache the object locally so as to avoid further calls to the system (e.g., READ requests) for the object for 24 hours. As mentioned above, typical HATEOAS systems provide information via the HTTP header, and max-age field <b>120</b> may constitute at least some of that information. As not all HTTP clients may be able to manage this information in the HTTP headers, typical configurations may effect unnecessary network traffic and server load. Further, by placing field <b>120</b> inside object <b>112</b>, each client <b>111</b> may manage its own caching of the object.

Object <b>112</b> further comprises zero or more links <b>122</b>, illustrated as an arbitrary number N links, each defining a relationship between the object and a related resource. Each link <b>122</b> may comprise, for example, “TYPE” element <b>124</b> defining the type of object returned by the link, “REL” element <b>126</b> defining the name of the relationship between object <b>112</b> and the returned object, URI element <b>127</b> identifying the resource providing the returned object, and “HREF” element <b>128</b> defining the location of the linked resource.

One non-limiting example of object <b>112</b> is an online shopping cart, as follows. Self entity <b>114</b> of the example shopping cart object includes a content type <b>116</b> of “application/vnd.elasticpath.cart” and an additional object field called “total-quantity” defined by the content type that indicates how many items are in the cart. In other words, the schema identified via content <b>116</b> may alert the receiving client to expect a “total-quantity” field.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry>self: {</entry></row><row><entry /><entry>type: “application/vnd.elasticpath.cart”,</entry></row><row><entry /><entry>href: “http://10.10.30.66/shapi/carts/rockjam/3456”,</entry></row><row><entry /><entry>uri: “/carts/rockjam/3456”</entry></row><row><entry /><entry>max-age: 0,</entry></row><row><entry /><entry>},</entry></row><row><entry /><entry>total-quantity: 10,</entry></row><row><entry /><entry>links: [</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>type: “application/vnd.elasticpath.links”,</entry></row><row><entry /><entry>href: “http://10.10.30.66/shapi/carts/rockjam/3456/lineitems”,</entry></row><row><entry /><entry>uri: “/carts/rockjam/3456/lineitems”,</entry></row><row><entry /><entry>rel: “lineitems”,</entry></row><row><entry /><entry>rev: “cart”</entry></row><row><entry /><entry>},</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>type: “application/vnd.elasticpath.order”,</entry></row><row><entry /><entry>href: “http://10.10.30.66/shapi/orders/rockjam/34453”,</entry></row><row><entry /><entry>uri: “/orders/rockjam/34453”,</entry></row><row><entry /><entry>rel: “order”,</entry></row><row><entry /><entry>rev: “cart”</entry></row><row><entry /><entry>},</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>type: “application/vnd.elasticpath.total”,</entry></row><row><entry /><entry>href: “http://10.10.30.66/shapi/totals/carts/rockjam/3456”,</entry></row><row><entry /><entry>uri: “/totals/carts/rockjam/3456”,</entry></row><row><entry /><entry>rel: “total”,</entry></row><row><entry /><entry>rev: “cart”</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>]</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In combination with self entity <b>114</b>, links <b>122</b> provide all the information necessary to implement a HATEOAS system, as described above. In other words, if object <b>112</b> is instructed (e.g., via user interaction, such as “clicking,” with representation <b>110</b>) to perform a state transition (e.g., follow link <b>122</b>), object <b>112</b> includes all information needed to access the link (e.g., how to contact server <b>102</b> in order to follow the link) and/or to manipulate the representation itself.

For example, during operation, client <b>111</b> may send resource operation request <b>132</b> corresponding to a particular link <b>122</b> in object <b>112</b> downloaded to client computing device <b>108</b>. The request is defined by HREF element <b>128</b> of the particular link <b>122</b>, and may include, for example, URL <b>131</b> indicating a location of the linked resource and action <b>133</b> indicating an action (e.g., PUT, GET, POST, or DELETE) to perform on the linked resource. For example, upon following an “add to cart” link, request <b>132</b> may include a request to POST an “add to cart” request to the “shopping cart” resource. In some embodiments, the request may further comprise user identifier <b>135</b>, which will be discussed in greater detail below. Such a request is provided for the purpose of example, and is not intended to be limiting in any manner.

Request <b>132</b> is sent to server <b>102</b> via computer network <b>109</b>, and is received at server <b>102</b> by acceptor <b>130</b> associated with microkernel <b>106</b>. Acceptor <b>130</b> performs processing of request <b>132</b>, and dispatches the request to an appropriate handler thread <b>134</b> of microkernel <b>106</b> for further processing. The handler thread, in turn, calls various resource servers <b>136</b> associated with various resources <b>138</b> in order to retrieve the requested data. For example, as illustrated, resources <b>138</b> may be stored in file systems <b>140</b> and/or databases <b>142</b>, or programmatically generated from data stored therein.

Based upon the processing of resource servers <b>136</b>, response <b>144</b> including object <b>146</b> is generated, and is subsequently transmitted via network <b>109</b> to client computing device <b>108</b>.

As with object <b>112</b>, client <b>111</b> may be configured, upon receiving object <b>146</b>, to provide representation <b>148</b> of object <b>146</b>. Specifically, client <b>111</b> may be configured to examine type <b>116</b> and/or the “REL” element of each link included within object <b>146</b> in order to provide representation <b>148</b>. For example, if client <b>111</b> identifies object <b>146</b> as a catalog entry (e.g., by examining type <b>116</b>), and if an “add to cart” link is not present within the object, client <b>111</b> may be configured to provide a disabled (e.g., “grayed-out”) add-to-cart button via representation <b>148</b>. In other embodiments, client <b>111</b> may be configured to display no “add to cart” button. It will be understood that these scenarios are presented for the purpose of example, and are not intended to be limiting in any manner.

Interaction with representation <b>148</b> (e.g., via clicking) may effect transmission of a second resource operation request and subsequent receipt of a third object (not illustrated). It will be appreciated that such interaction may be repeated ad infinitum and/or until a desired state is reached.

Turning now to <figref idref="DRAWINGS">FIG. 2</figref>, a non-limiting example of a HATEOAS system <b>200</b> in accordance with another embodiment of the present disclosure is schematically illustrated. System <b>200</b> comprises server <b>202</b> communicatively coupled to HTTP client <b>204</b> via network <b>206</b>. Server <b>202</b> is configured to receive, via acceptor <b>208</b>, request <b>210</b> from client <b>204</b> and to send, via the acceptor, response <b>212</b>. Server <b>202</b> includes kernel <b>214</b> configured to interact with the remaining elements of the server, thereby acting as the “central communications hub” of server <b>202</b>. For example, kernel <b>214</b> may provide a handler thread <b>215</b> to handle the described request-response lifecycle. Server <b>202</b> yet further includes authorization solver <b>216</b> and resource linker <b>218</b>. The resource linker may utilize the authorization solver to determine if a particular resource server is authorized to attach links, as is discussed in greater detail below.

Server <b>202</b> includes one or more object servers <b>220</b> and one or more link resource servers <b>222</b>, each sometimes referred to as “resource servers.” Although object servers <b>220</b> and link resource servers <b>222</b> are illustrated via an arbitrary number N of object servers and an arbitrary number N of link resource servers, respectively, it will be appreciated that such illustration is provided for ease of understanding, and that server <b>202</b> may include additional and/or different resource servers in other embodiments without departing from the scope of the present disclosure. It will be further appreciated that although object servers <b>220</b> and link resource servers <b>222</b> are illustrated as distinct components, any particular resource server may operate as an object server or a link resource server, depending on the particular request <b>210</b>, as will be described in more detail below.

The object servers <b>220</b> and link resource servers <b>222</b> are distinct software programs configured to interact with each other by exchanging, i.e., sending and/or receiving, resource operations via kernel <b>214</b>. Each resource server operates independently from the others and is the only resource server that serves data objects for its resource. In other words, no resource servers other than the resource server corresponding to a particular resource <b>224</b> are able to directly interact with or modify the resource. For example, in the depicted configuration, “Object Server 1” may not directly interact with resources <b>224</b> other than “Resource 1.” Such a configuration may therefore enable the implementation of business rules and/or other logic associated with a particular resource <b>224</b> within the associated resource server. In this way, each object server <b>220</b> and/or link resource server <b>222</b> is responsible for a particular resource <b>224</b> (e.g., e-commerce platform, inventory management system, data management system, database, file system, etc). For example, in an e-commerce scenario, one of the resource servers may be a “price” resource server configured to provide requested price(s), and all pricing-related logic (e.g., bulk discounts, sales, other promotions, etc.) may be implemented by the “price” resource server and only the “price” resource server.

An example request-response lifecycle of system <b>200</b> is as follows. Request <b>210</b> comprises a request to retrieve (e.g., READ) a particular resource of resources <b>224</b>. Upon receiving request <b>210</b> from client <b>204</b> via acceptor <b>208</b>, kernel <b>214</b> is configured to provide the request to the resource server identified by the request. In some embodiments, kernel <b>214</b> may be configured to parse the URI identified by the request (e.g., URI derived by acceptor <b>208</b> from URL <b>131</b>) to determine the corresponding resource server. In other embodiments, kernel <b>214</b> may be configured to determine the corresponding server via one or more other mechanism(s). As illustrated, kernel <b>214</b> provides resource operation request <b>226</b> to “Object Server 1,” and microkernel <b>214</b> receives object <b>228</b> in response. Object <b>228</b> corresponds to the resource (i.e., “Resource 1”) providing the object server, and represents the state of the resource after performance of the resource operation request.

Upon receiving object <b>228</b>, microkernel <b>214</b> is configured to provide the object to resource linker <b>218</b> in order to aggregate, and to subsequently attach to the object, any one or more links <b>230</b> provided by the remaining resource servers (e.g., by link resource servers <b>222</b>). In other words, the resource linker is configured to collect links with additional, related information from the other resource servers.

In an example e-commerce scenario, object <b>228</b> may represent a product entry in an online catalog. For example, request <b>210</b> may comprise a request for a product information “page” for a particular product, where the “page” includes a description, price, and indication of available inventory for the product. Thus, the example object <b>228</b> received from the appropriate object server <b>220</b> comprises a catalog entry object corresponding to the product. For example, object <b>228</b> may comprise a product identifier (e.g., product ID, product title, etc.) and/or additional information such that the remaining resource servers may provide information related to the product (e.g., description, pricing, etc.).

Accordingly, once object <b>228</b> is received at resource linker <b>218</b> via microkernel <b>214</b>, the resource linker is configured to provide the object to the one or more link resource servers <b>222</b> in order to populate the catalog entry through receipt, and subsequent embedding, of links <b>230</b>. For example, link resource servers <b>222</b> in this scenario may include a price resource server, an inventory resource server, a product description resource server, and a shipping resource server. Each of the resource servers, upon receiving object <b>228</b> from the resource linker, may examine the object, and respond with any relevant links <b>230</b>. Thus, the object may be augmented with price data returned by the price resource server, inventory data returned by the inventory server, description data returned by the product description server, and shipping information returned by the shipping resource server. Generally speaking, each link resource server <b>222</b> may implement one or more linking rules <b>229</b> (e.g., business rules, other logic, etc.) to determine which link(s) to return for a given object <b>228</b>. The result of such linking, as discussed above in reference to <figref idref="DRAWINGS">FIG. 1</figref>, is stored within the object, and is eventually returned to the requesting client.

Although the above description pertains to so-called monolithic resources servers (e.g., shipping resource server to provide shipping information), there may be one or more subresources <b>232</b> for each of any one or more resources <b>224</b> in some embodiments. Each subresource <b>232</b> may be utilized to provide additional information to a given resource <b>224</b>. Accordingly, subresources <b>225</b> may be added, deleted, or modified without any update to the associated resource, thereby potentially further increasing the extensibility of system <b>200</b>. The subresources, along with the rest of the resources, are queried during linking to determine if the subresources have related information. For example, returning to the above e-commerce scenario, although the shipping resource exists to provide shipping information (e.g., shipping method selection, pricing, estimated delivery, etc.), it is each subresource that may define the individual shipping options (e.g., 3-day), etc. Thus, if a new shipping option (e.g., overnight) becomes available, a new subresource <b>232</b> can be created to define said option without updating the parent “shipping” resource. In such scenarios, after the shipping resource has handled a “shipping” resource operation, the linker may query the subresources to determine additional details.

In order to provide information related to object <b>228</b>, each link resource server <b>222</b> may be configured to examine the “type” element of object <b>228</b> (e.g., TYPE <b>116</b>), as more than one object encountered by a particular resource server may comprise similar, or equivalent, names (e.g., REL <b>126</b>). Each resource server may implement one or more functions, and each of these functions may be defined for any one or more object types. In other words, each resource server may be configured to perform type-granular resource operations on a corresponding resource of resources <b>224</b>. For example, a “shopping cart” resource server may be configured to not provide an “add to cart” link to an object of “image” type, but may be configured to provide such a link to an object of “product” type. As another example, upon encountering an object type for which no corresponding logic exists (e.g., new object type) at a particular resource server, the resource server may be configured to provide no links <b>230</b>. It will be understood that, depending on the particular use case scenario and/or configuration of server <b>202</b>, links <b>230</b> may include “direct” information and/or “indirect” information (e.g., information usable to programmatically retrieve other information). For example, in some embodiments, the product description resource server may be configured to provide a text-based description of the product such that the information provided in the link(s) is directly usable to provide the product description. In other embodiments where the information is “indirect,” the information provided by the product description resource server may be usable by client <b>204</b>, upon receipt, to programmatically retrieve the product description (e.g., from the product description resource server).

In some instances, one or more of link resource servers <b>222</b> may not be able to provide links <b>230</b>, and may instead perform, in response to the query, a “default action.” In some instances, such a default action may include, for example, providing an error status (e.g., “Out of stock” notification), providing a link to an error status (e.g., link to error status with up-to-date information), and/or providing nothing (e.g., no response, response with no data payload, etc.). In other instances, a resource server may provide different and/or additional default actions without departing from the scope of the present disclosure.

Generally speaking, resource linker <b>218</b> is configured to collect any information related to object <b>228</b>. Accordingly, resource linker <b>218</b> may be configured to provide object <b>228</b> to every resource server of server <b>202</b>. Thus, the resource linker may be configured to maintain an understanding of all of the resource servers (e.g., via a resource server list, etc.) of server <b>202</b>. As mentioned previously, each resource server may be substantially independent of the other resource server(s). Therefore, linker <b>218</b> may be configured to query the resource servers in any desired order, so long as each resource server is queried. For example, in some embodiments, linker <b>218</b> may query one or more of the resource servers in parallel to increase throughput.

Regardless of the order by which the resource servers are queried, the resource server is aware that linking is complete for a particular object once all resource servers have been queried. As object <b>228</b> is passed to each resource server, and as each resource server is configured to provide information, i.e., links, independent of the information provided by the other resource server(s), it will be appreciated that the links are not embedded within the object until all link(s) have been collected from all of the resource servers. Once all the links have been collected and embedded in the object, the object is returned to the requesting client.

Although operation of resource linker <b>218</b> has been described with reference to interactions between the linker and one or more resource servers, it will be appreciated that such interaction may be provided via kernel <b>214</b>. As mentioned above, the resource servers are isolated modules configured to interact with each other by exchanging (e.g., sending and/or receiving) resource operations via kernel <b>214</b>. Accordingly, in order to query a particular resource server, linker <b>218</b> may be configured to provide a query resource operation (e.g., READ operation) for the particular resource server to the kernel, and the kernel may subsequently provide the query to the corresponding resource server. Similarly, the link(s) provided by the resource server may be received by linker <b>218</b> via kernel <b>214</b>.

As mentioned above, HATEOAS systems are, by design, typically unaware of the concept of “users,” and may therefore be ill-suited for e-commerce scenarios and/or for other applications utilizing user-based permissions, preferences, etc. Accordingly, server system <b>200</b> further includes authorization solver <b>216</b> so as to provide kernel <b>214</b> with user authentication needed for the improved HATEOAS architecture. Specifically, after microkernel <b>214</b> receives a resource operation (e.g., resource operation request <b>226</b>, linking operation requests, etc.), the kernel may be configured to communicate with the authorization solver to ensure that the given resource operation is allowed. In other embodiments, the kernel may forward a subset of the resource operation request data.

For example, in some embodiments, request <b>210</b> may further comprise a user identifier (e.g., user identifier <b>135</b>) indicating the user providing the request. The user identifier may comprise any data, or combination of data, used to determine the permissions of a given user. For example, in some embodiments, the user identifier may be a substantially unique identity (e.g., user name). In other embodiments, the user identifier may define a role (e.g., administrator) with which permissions are associated, and the role may be shared amongst any one or more users. Generally speaking, request <b>210</b> may comprise at least some identifying information such that server system <b>202</b> may examine this information to determine whether or not the resource operation identified by the request is allowed to be performed.

Accordingly, upon receiving request <b>210</b>, kernel <b>214</b> (e.g., handler <b>215</b> of kernel <b>214</b>) may be configured to determine the user identifier, role identifier, and/or other identifying information, and may thus supply authorization solver <b>216</b> with this information. Authorization solver <b>216</b> may then be configured to examine the information, and to provide an indication (e.g., yes/no, detailed result, etc.) to kernel <b>214</b> as to whether or not the request should be handled. In other embodiments, kernel <b>214</b> may forward request <b>210</b> to authorization solver without first identifying a user, role, etc. It will be appreciated that these scenarios are presented for the purpose of example, and are not intended to be limiting in any manner. The interaction between the various elements of <figref idref="DRAWINGS">FIG. 2</figref> will now be discussed in greater detail with reference to <figref idref="DRAWINGS">FIG. 3</figref>.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a process flow depicting an embodiment of a method <b>300</b> for serving a resource to a client via a computer network at an HTTP server system (e.g., server <b>102</b>, server <b>202</b>, etc.) having a stateless microkernel architecture. At <b>302</b>, method <b>300</b> comprises receiving an HTTP request (e.g., request <b>132</b>) for a resource from an HTTP client via a computer network, where the request is to perform a resource operation. The resource operation may comprise, for example, a request to retrieve the resource (e.g., a READ operation) and send the resource to the requesting client. In order to effect the resource operation, the request may include, for example, a user identifier, a resource URI, and an action to perform on the resource identified by the URI. Although method <b>300</b> is described herein with reference to a READ operation, in other scenarios, in accordance with the HATEOAS architecture, the action may be one of: POST, GET, PUT, or DELETE (sometimes referred to as CREATE, READ, UPDATE, and DELETE, respectively). As previously described, the user identifier may comprise any data, or combination of data, used to determine the permissions of a given user.

At <b>304</b>, method <b>300</b> further comprises determining if the resource operation is authorized based on the request. In some embodiments, such a determination may comprise determining a user identifier based on the request and querying an authorization solver (e.g., authorization solver <b>216</b>) to determine whether a user corresponding to the user identifier is authorized to perform the resource operation. For example, a kernel of the HTTP server system (e.g., kernel <b>214</b>) may be configured to determine the user identifier from the request (e.g., by parsing the request), and to query the authorization solver by providing the user identifier. In other embodiments, the entire request and/or a different subset of the request may be provided to the authorization solver. If the resource operation is not authorized, method <b>300</b> ends, and thus the resource operation is not performed. In some embodiments, a message indicating the operation failure may be sent to the requesting client.

However, if the resource operation is authorized, method <b>300</b> further comprises, at <b>306</b>, sending the resource operation to an object server associated with the resource identified by the request. For example, as mentioned above, the kernel of the server system may be configured to determine the user identifier by parsing the user request, and such parsing may further comprise parsing a link included in the request to identify the requested resource. In other embodiments, parsing of the link may be performed upon determining that the resource operation is allowed. Nonetheless, determining which particular resource is requested may be accomplished by recognizing a URI of the resource within the request. These scenarios are presented for the purpose of example, and are not intended to be limiting in any manner.

In response to sending the resource operation to the object server, method <b>300</b> further comprises, at <b>308</b>, receiving an object from the object server, where the object represents the resource upon performance of the resource operation. In other words, the object may represent the “result” of the resource operation. For example, as the request includes a GET (READ) action (e.g., retrieve the resource), the object may represent the state of the resource upon performance of the GET action. In other embodiments where the request includes a POST (UPDATE) action (e.g., update the resource with new information), the object may represent the state of the resource after the resource has been updated with the new information.

At <b>310</b>, method <b>300</b> further comprises embedding, in the object, a content type identifier (e.g., TYPE <b>116</b>) indicating a content type of the object and a resource location identifier (e.g., HREF <b>118</b>) indicating a location of the resource. As mentioned previously, typical HATEOAS systems embed such identifying information within the HTTP header itself. However, as this increases dependency upon the HTTP protocol itself, such a configuration may not provide suitable extensibility and/or may be otherwise undesirable. Accordingly, by embedding the information within the object, the identifying information remains with the object while freeing the HTTP header to provide the “standard” functionality.

As described above, handling of a READ operation may include not just returning a particular object (if at all), but may also comprise determining related information. For example, if the request received at <b>302</b> includes a request for an online shopping cart, merely returning the shopping cart object (e.g., cart comprising a list of items) without related information (e.g., price, inventory, etc.) may be undesirable. In such scenarios, the client may be configured to provide one or more calls for the additional information, thereby increasing the complexity of the client and/or decreasing throughput. As such, it may be desirable to both determine the related information and attach the information to the object before returning the object to the requesting client.

Accordingly, at <b>312</b>, method <b>300</b> further comprises providing, via a linking engine (e.g., resource linker <b>218</b>), the object to each link resource server of the one or more link resource servers. As discussed above, the resource linker is configured to query each of the resource servers to determine if said resources servers are aware of any information related to the resource operation. Said querying may be accomplished, for example, by utilizing the method of <figref idref="DRAWINGS">FIG. 3</figref>. In other words, the linker may query the resource servers by constructing a resource operation for each resource server. In some embodiments, authorization may be performed instead of, or in addition to, the authorization performed at <b>304</b>. For example, authorization may be performed upon receiving the object and/or before providing each linking resource operation.

As said resource operations result from a “primary” resource operation, said resource operations may be referred to as “secondary” resource operations. By allowing non-kernel elements of the microkernel to query other elements, each element does not need to be “aware” of the state of any other resource since the state can be queried as needed. Such a configuration ensures that only the appropriate resource server acts upon a given resource operation, and that any other resource server must interact with the resource server instead of directly accessing the resource.

In order to provide the related information, each link resource server may be configured to examine the (embedded) content type of the object. Generally speaking, each link resource server includes “linking rules” (e.g., business rules, other logic, etc.) for one or more object types. Accordingly, upon recognizing the content type of the object as a content type for which linking rule(s) exist, each resource server is configured to return one or more links according to the linking rules corresponding to the content type of the object. As mentioned above, if a particular link resource server does not recognize the object type, or otherwise cannot provide a response to the query, the link resource server may be configured to provide a “default action.” It will be understood that each resource server receives the object, and does not receive any links provided by the other resource servers. In other words, there may exist no pre-defined order by which the resource servers are queried, and instead the resource servers may be queried in any particular order, so long as each of the link resource servers is queried. In some embodiments, two or more of the resource servers may be queried in parallel.

Thus, in response to the provision at <b>312</b>, method <b>300</b> further comprises, at <b>314</b>, receiving one or more links from each of the one or more link resource servers. In some instances, there may be no suitable links. At <b>316</b>, method <b>300</b> further comprises embedding the links in the object (e.g., within a “links” data structure/field/etc.). Upon embedding the links, method <b>300</b> comprises sending the object to the requesting client via the computer network at <b>318</b>.

Turning now to <figref idref="DRAWINGS">FIG. 4</figref>, a process flow depicting an embodiment of a method <b>400</b> for operating a stateless microkernel architecture server including a first link resource server and a second link resource server is illustrated. At <b>402</b>, method <b>400</b> comprises receiving an HTTP request for a resource from an HTTP client via a computer network, the request being to perform a resource operation, the resource operation being to retrieve the resource and send the resource to the requesting client, wherein the resource is a data object.

At <b>404</b>, method <b>400</b> comprises sending the resource operation to an object server associated with the resource identified by the request. At <b>406</b>, method <b>400</b> further comprises, in response, receiving the data object from the object server, and, at <b>408</b>, embedding, in the data object, a content type identifier indicating the a content type of the data object and a resource location identifier indicating a location of the resource. In other words, the requested data object has been received and the identifier(s) have been embedded in the object. However, it will be appreciated from the preceding discussion that one or more link resource servers may maintain information that is related to the data object.

Accordingly, at <b>408</b>, method <b>400</b> further comprises providing the data object to the first link resource server via a linking engine. In response, at <b>410</b>, method <b>400</b> further comprises receiving one or more first links from the first link resource server. Similarly, at <b>412</b>, method <b>400</b> comprises providing the data object to the second link resource server via the linking engine, Method <b>400</b> further comprises, at <b>414</b>, in response, receiving default information from the second link resource server. The default information may be received, for example, if the second link resource server does not maintain information related to the object and/or if the second link resource server is unavailable. As previously mentioned and as illustrated at <b>416</b>, the default information may include one or more of a link to a status of the second link resource server, and a status notification.

Method <b>400</b> further comprises, at <b>418</b>, embedding the one or more first links in the data object. In some embodiments, method <b>400</b> may further comprise, at <b>420</b>, if the default information includes the link to the status of the second link resource server, appending the link to the status of the second link resource server to the data object before sending the object to the requesting client. In other words, if the default information includes a link, the link is embedded in the object. At <b>422</b>, method <b>400</b> further comprises sending the object to the requesting client via the computer network.

As described above, one potential advantage of utilizing the REST HATOEAS software architecture is the ability to represent, and to effect a change in, application state over a computer network via linked hypermedia. For example, by sending a POST request including data to be posted to a server, a corresponding resource on the server may be updated to reflect the posted data. After the resource has been updated, typical REST HATEOAS server systems may be configured to return a link to the client that indicates the location of the updated resource. The client may subsequently utilize the returned link to retrieve the updated object by sending a GET request for the resource based on the link. In other words, in order to both effect a system state transition and retrieve object(s) modified thereby, a client in a typical REST HATEOAS system may be expected to provide two different requests to the server. Such a configuration may thus be undesirable, for example, due to decreased throughput caused by the increased network traffic.

It will therefore be appreciated that it may be desirable to provide streamlined mechanism(s) for providing state transitions in a client-server system. Turning now to <figref idref="DRAWINGS">FIG. 5</figref>, the example HATEOAS-based client-server system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref> is illustrated. However, <figref idref="DRAWINGS">FIG. 5</figref> further comprises follow location handler <b>502</b> logically positioned between server <b>102</b> and client <b>111</b>. In other words, the follow location handler is logically positioned on a WAN side of server <b>102</b>. Although follow location handler is illustrated as being external to server <b>102</b>, generally speaking, follow location handler <b>502</b> may be executed on a same computing device as HTTP server program <b>104</b>, or on a computing device connected via a LAN (not illustrated) to the computing device on which the HTTP server is executed. In some embodiments, server <b>102</b> may be unaware that follow location handler is interacting with the network traffic.

As previously described with reference to <figref idref="DRAWINGS">FIG. 1</figref>, client <b>111</b> is configured to follow a particular link of links <b>122</b> embedded in object <b>112</b> by sending request <b>132</b> to server <b>102</b> via network <b>109</b>. In the previous discussion, if the request is operable to retrieve a particular resource of resources <b>138</b>, response <b>144</b> received from the server system comprises the requested object. In contrast, if the request is operable to effect a state transition, such as by posting information to the resource, the response in a typical REST HATEOAS system may comprise a link to the corresponding updated data object. The client may thus be expected to provide a separate READ request to retrieve the object, if desired.

Generally speaking, follow location handler <b>502</b> is configured to act as a server-side middleman between server <b>102</b> and client <b>111</b> by intercepting and selectively forwarding information, such as requests <b>132</b> and responses <b>144</b>, between the sever and the client. In other words, upon recognizing particular requests <b>132</b> or responses <b>144</b>, follow location handler <b>502</b> may be configured to forward the requests and the responses to the intended destination. Furthermore, upon recognizing other responses <b>504</b> from server <b>102</b>, follow location handler <b>502</b> may be configured to programmatically generate one or more requests <b>506</b> to server <b>102</b> without providing responses <b>504</b> to the client. Example operation of a server system comprising an embodiment of a follow location handler <b>502</b> will now be discussed with reference to <figref idref="DRAWINGS">FIG. 6</figref>.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flowchart depicting an embodiment of a method <b>600</b> of serving a resource from an HTTP server (e.g., server <b>102</b>) to a client (e.g., client <b>111</b>) via a computer network. At <b>602</b>, the client sends a POST request (e.g., request <b>132</b>) including form data <b>604</b> via the WAN. In other words, the request includes information to be applied to a resource, and the action to be performed on the resource so as to provide such application. A follow location handler (e.g., follow location handler <b>502</b>), receives the POST request at <b>606</b>, and, at <b>608</b>, forwards the POST request to the server system. In other words, the follow location handler may be configured to recognize the received request as a POST request and to subsequently forward the request to the server so that the server can attempt to fill the request.

The server receives the post request at <b>610</b>, and, at <b>612</b>, creates a modified data object based upon the form data. In other words, upon posting the form data to the resource, the state of the resource is updated, and the server is configured to update the data object accordingly. Since the request is a POST request, as opposed to a GET request or other operation where one or more objects are to be returned, the server system generates a link to the modified data object at <b>614</b>, and, at <b>616</b>, returns the link to the modified object.

In some embodiments, for example, where the follow location handler and the server are substantially cooperating, the server may be configured to send the link to the modified object directly to the follow location handler. In other embodiments, for example, where the follow location handler is substantially transparent to the server, the follow location handler intercepts the link to the modified data object from the server at <b>618</b>. Regardless of how the link arrives at the follow location handler, the follow location handler refrains from forwarding the link to the requesting client over the WAN at <b>620</b>. As mentioned above, if the link to the modified data object were to be forwarded to the client, the client would be expected to generate a second request to retrieve the updated object, if desired. In contrast, the follow location handler may be configured to send a GET request to the server to retrieve the modified data object via the intercepted link at <b>622</b>. In other words, the handler may receive the link, prevent the link from being provided to the client, and programmatically provide a request for the updated data object identified by the link. It will be appreciated that such operation may be substantially transparent to the server and/or the client.

At <b>624</b>, the server receives the GET request. As previously described with reference to <figref idref="DRAWINGS">FIG. 2</figref>, before returning a requested object, a REST HATEOAS system in accordance with embodiments of the present disclosure may be configured to perform linking in order to embed information related to the object within the object itself. Thus, in some embodiments, the server may be configured to perform linking at <b>626</b>. Regardless of whether or not such linking is performed, the server system returns the modified data object at <b>628</b>.

At <b>630</b>, the follow location handler receives the modified data object, and, in response, forwards the modified data object to the client at <b>632</b>. The client thus receives the modified data object at <b>634</b>. Upon receiving the modified data object, the client may be configured, for example, to update the entire representation of the object and/or to update a portion of the representation. In other embodiments, the client may not update the representation. From the discussion of <figref idref="DRAWINGS">FIG. 6</figref>, it will be appreciated that a follow location handler in accordance with embodiments of the present disclosure may be configured to effect a second request, and handle the response thereto, upon recognizing a request from a client. In other words, such a configuration may enable the performance of compound resource operations in a manner that is substantially transparent to the client and/or the server.

In some embodiments, client-server interaction may be related to user-interaction with a form. Forms comprise one or more control objects enabling a user to provide information to the server for further processing. Forms are utilized by many pages on the World Wide Web to provide functionality such as providing user feedback, inputting address and/or payment information, performing search queries, and the like.

For example, <figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of an embodiment of a form <b>800</b> for performing a real estate search, for example, by querying a real estate database. Form <b>800</b> includes text input mechanism <b>802</b> to receive text-based form data in the way of one or more keywords. If a user wishes to search via keyword(s), text is entered via mechanism <b>802</b> and the form data is submitted upon actuation of POST mechanism <b>804</b>, illustrated in the form of a “search” button. Returning briefly to <figref idref="DRAWINGS">FIG. 5</figref>, follow location handler <b>502</b> may be configured to recognized such a request, and may be further configured to handle response <b>504</b> and request <b>506</b> such that response <b>144</b> returned to client <b>111</b> includes an object comprising the search results. In other instances where such follow location functionality is not provided, a link to a search results object may be returned, and the client providing form <b>800</b> may be expected to provide a second request to retrieve the search results.

Returning to <figref idref="DRAWINGS">FIG. 8</figref>, manual information entry of form data may be undesirable in some instances, such as, for example, when particular information is constrained to a finite set of allowable information. Therefore, form <b>800</b> further comprises selectors <b>806</b>, such as neighborhood selector <b>806</b><i>a</i>, bedroom selector <b>806</b><i>b</i>, baths elector <b>806</b><i>c</i>, and size selector <b>806</b><i>d</i>. Each selector <b>806</b> is configured to provide a plurality of selection options <b>808</b> for selection by the user. In the illustrated example, neighborhood selector <b>806</b><i>a </i>receives input of a desired neighborhood by allowing a user to select a particular selection option from the selection options <b>808</b><i>a </i>of “Downtown,” “East,” “West,” and “Suburbs.” In other words, a user interacting with form <b>800</b> is therefore able to define a state of neighborhood selector <b>806</b><i>a </i>by selecting one or more of the selection options of selection options <b>808</b><i>a</i>, and the state of selector <b>806</b><i>a </i>may not be set to a state that does not correspond to one or more of selection options of selection options <b>808</b><i>a</i>. Further, selector <b>806</b><i>a </i>may be populated only with selection options <b>808</b><i>a </i>that are valid and selectable given the current state of form <b>800</b>. Relationships between selectors <b>806</b> will be discussed in greater detail below.

In some embodiments, form <b>800</b> may further comprise selectors <b>806</b><i>e</i>, <b>806</b><i>f</i>, and <b>806</b><i>g</i>. These selectors are illustrated in the form of checkboxes, and are configured to provide two potential states. In other words, selectors <b>806</b><i>e</i>, <b>806</b><i>f</i>, and <b>806</b><i>g </i>enable selection of one of two pre-defined potential states, e.g., TRUE or FALSE, YES or NO, ON or OFF, etc. Although the configuration of selectors <b>806</b> is provided for the purpose of example, it will be appreciated that these configurations are not intended to be limiting in any manner.

Before continuing with the discussion of <figref idref="DRAWINGS">FIG. 8</figref>, implementation of selectors via the described improved HATEOAS REST architecture will be described with reference to <figref idref="DRAWINGS">FIG. 7</figref>. As mentioned above, state modifications are typically performed by issuing a POST command to provide form data to a resource, issuing a PUT command to update a resource, and/or issuing a DELETE command for a resource. In some embodiments, a particular current state may correspond to a finite set of potential state transitions. For example, an e-commerce system may be configured to only serve customers living within North America. Accordingly, during checkout, a user of such a system may be able to select a country for a delivery address from a selection of countries in North America. In this way, the business rules limiting sales to North America may be implemented by constraining the selection of shipping destination countries to countries within North America.

<figref idref="DRAWINGS">FIG. 7</figref> schematically illustrates object <b>700</b> in the form of a selector object. From the preceding discussion, it will be appreciated that identification of the object as a selector object is accomplished by defining a selector schema via type <b>116</b> of self entity <b>114</b>. Self entity <b>114</b> further includes HREF <b>118</b> that points to the location of the resource server that provided selector object <b>700</b>.

Selector object <b>700</b> further comprises a plurality of links <b>122</b>, referred to herein as “selection options” when embedded in a selector object. As each selection option corresponds to a potential state of the selector object, each link <b>122</b> that serves as a selection option includes a description of the selection indicated by REL element <b>126</b> and a corresponding action indicated by HREF element <b>128</b>. For example, in some scenarios, the action may include posting the selection option selected by a user, referred to simply as a “selection,” to the resource at location <b>118</b>. In other words, upon selecting a particular selection link <b>122</b>, HREF <b>128</b> associated with the selection may be followed in order to effect the corresponding state transition.

In some embodiments, selector object <b>700</b> may be generated by a selector resource server, and the selector object may be provided to each resource server in order to effect linking of the one or more selection options. Accordingly, if selector object <b>700</b> corresponds to an address selection menu, a plurality of selection options <b>122</b> may be provided by a user accounts resource server, where each selection option <b>122</b> corresponds to a stored address for a user.

As briefly mentioned above, the schema identified by TYPE element <b>116</b> may indicate the presence of one or more additional, type-specific fields within the object. Thus, in some embodiments, selector object <b>700</b> may further comprise selection rules <b>702</b> and/or current state <b>704</b>. Selection rules <b>702</b> may include any one or more rules defining the selection behavior of selector object <b>700</b>. The selection rules may indicate, for example, how many selectors, if any, may be simultaneously chosen. For example, it may be desirable in an e-commerce scenario to ensure that a user is able to select only one destination country. Current state <b>704</b> may be usable to determine the state of the resource on the server that is represented by selector object <b>700</b>, thereby enabling representation of the current state.

Returning to <figref idref="DRAWINGS">FIG. 8</figref>, relationships between the selectors will now be described. During linking, one or more resource servers may be configured to examine a selector object and, in response, provide one or more selection options for embedding in the object. As each resource may be related to any one or more other resources, it will be appreciated that the provision of one or more of the selection options may depend on the state of one or more other selectors and/or the state of one or more other resources.

Thus, as the user interacts with each selector in the control and makes a selection of a selection option, client side logic in the selector causes a POST command to be programmatically issued upon the client receiving the selection without waiting for the page to be reloaded or the form to be posted by the user via a “submit” selector, etc. Each time a selector state changes in the control, a POST command is issued and the state of the entire control is updated, thus ensuring that only relevant and selectable selection options are presented to the user in the control.

In the illustrated form <b>800</b>, selection options <b>808</b> provided by size selector <b>806</b><i>d </i>may depend upon the state of neighborhood selector <b>806</b><i>a</i>. For example, if available real estate in the downtown neighborhood is all less than 3,000 square feet, a query for real estate that is both in downtown and over 3,000 square feet may provide zero results, and such a state may not be allowed by an example system. Accordingly, upon selection of the “Downtown” selection option of selection options <b>808</b><i>a</i>, the selection may be posted to the server, and an updated selector object corresponding to size selector <b>806</b><i>d </i>may be received that does not include the “3,000+” selection. In other embodiments, the updated selector object may include such disabled selection(s) such that the receiving client is able to provide representation <b>810</b> of the disabled resource. Although illustrated as a crossed-out selection option of selection options <b>808</b><i>b</i>, it will be appreciated that representation <b>810</b> is provided for the purpose of example, and that the representation of disabled selectors may have different representations, if any. As another example of relationships between selectors <b>806</b>, upon selection of the downtown neighborhood, selector <b>806</b><i>a </i>providing binary selection options of a garage option may be disabled and set to a FALSE state, indicating that no real estate corresponding to the states of selectors <b>806</b> includes a garage. In such instances, selector <b>806</b><i>g </i>may be grayed-out or otherwise disabled, as illustrated by the dashed outline, though other representations are possible without departing from the scope of the present disclosure.

The above systems and methods may be utilized to realize a complex, stateful system according to the REST HATEOAS architecture. Generally speaking, by clustering business rules and/or other logic associated with a particular resource around the associated resource server, each resource may be individually maintained while still providing for instantiation of inter-resource relationships. For example, such a configuration may enable the provision of complex forms including a plurality of interrelated selectors. Further, as each resource server is substantially independent of the other resource servers, such a configuration may provide greater extensibility by enabling resource-granular updating of the logic. Yet further, by implementing the complex logic within the server as opposed to the clients, the described systems may potentially allow for lighter-weight client(s) as compared to typical client-server systems.

The above systems and methods may be further usable to provide streamlined mechanisms for handling network-based state transitions. For example, by providing a follow location handler configured to selectively intercept information so as to programmatically affect further requests to a server, a single request may be provided to both effect a state change and retrieve an updated object without defining any specialized instructions.

As this invention may be embodied in several forms without departing from the spirit of essential characteristics thereof, the present embodiments are therefore illustrative and not restrictive, since the scope of the invention is defined by the appended claims rather than by the description preceding them, and all changes that fall within metes and bounds of the claims, or equivalence of such metes and bounds thereof are therefore intended to be embraced by the claims.