Stateless Microkernel Web Server Linking Engine
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The REST HATEOAS architecture has several deficiencies, including dependency on the HTTP protocol, inflexibility in server location, lack of user operation concepts, difficulty in asynchronous communication with runtime executable programs, and complexity in handling state transitions in complex systems.
Innovation Solution
The solution involves embedding self entities within resources to store URI and other metadata, introducing resource operations with authorization, and clustering business logic around resource servers to manage state transitions and links, allowing for protocol independence and improved scalability and user authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If REST HATEOAS architecture uses HTTP protocol headers to transmit resource information, then resource identification and content type are conveyed, but the system becomes dependent on HTTP protocol and unusable with other protocols
Solution Approach 1:
The patent extracts resource identification information (URI, content type, location) from HTTP protocol headers and embeds it directly within the resource data structure itself. This allows the resource to be self-describing and protocol-agnostic, eliminating dependency on HTTP-specific header mechanisms while maintaining all necessary identification and routing capabilities.
2Productivity
If HATEOAS systems embed all state information in hypermedia links, then stateless interactions are achieved, but additional HTTP header information is required and processing becomes difficult
Solution Approach 1:
The patent merges previously separate concerns (resource state information, identification data, and linking metadata) into a unified resource data structure. By consolidating URI, content type, and location information within the resource object itself rather than requiring separate HTTP headers, the system simplifies processing while maintaining stateless interaction efficiency.
3Adaptability or versatility
If URL is used as resource identifier in HATEOAS, then resource location is specified, but the system becomes tied to specific server instances and loses flexibility in scaled deployments
Solution Approach 1:
The patent segments the resource identification system into two distinct components: a stable, protocol-independent URI that identifies the logical resource, and a dynamic location field that specifies the current server instance. This separation allows resources to be reliably identified regardless of which server instance hosts them, enabling flexible scaled deployments where resources can migrate between servers while maintaining stable identification.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method of serving a resource to a client via a network is provided. The method may include at an HTTP server system having a stateless microkernel architecture with one or more link resource servers, receiving an HTTP request from an HTTP client to perform a resource operation to retrieve a resource data object. If the resource operation is authorized, the method may include sending the resource operation to an object server associated with the resource identified by the request, and in response receiving a data object from the object server; providing, via a linking engine, the data object to each link resource server of the one or more link resource servers; and in response receiving one or more links from each of the one or more link resource servers, embedding the links in the data object, and sending the data object to the requesting client via the computer network.