| Internet-Draft | crest | November 2024 |
| Tulshibagwale | Expires 25 May 2025 | [Page] |
The REST architecture is extremely popular in modern computing environments. A benefit it provides is that each request can be serviced by independent server side components such as different instances of web servers or different instances of serverless request handlers.¶
The lack of any context associated with a request means that the client has to provide the entire context with every request. In monolithic server-side architectures the client typically only provides an identifier to a previously established "session" on the server side, which is retrieved from a persistent storage such as a database.¶
However, this strategy often does not work in microservices architectures, where the persistent storage may be many hops away from the server-side components that handle the incoming REST API requests. As a result, REST APIs are used between services and each request is required to carry large context including tokens such as Transaction Tokens [TRATS] (which assure the identity and context of each request), SPIFFE [SPIFFE] tokens (which assures the service identity) and possibly other context.¶
The Contextualized REST (CREST) architecture adds a cached context to REST, with mechanisms to negotiate the establishment of the context when it is not found. Each request can refer to the context items it depends upon instead of carrying the entire context with the request. The server can accept the reference to the context item or respond with a specific error to prompt the client to reestablish the context. Clients can create new or delete existing context items in separate requests or as a part of other requests.¶
The CREST architecture assumes the server holds the context across different requests in a server-side cache. Such a cache may be typically shared across various applications and services within a VPC or a data center. The possibility that subsequent requests from the same client will reach different VPCs or data centers is low, thus providing an efficiency optimization for the vast majority of requests.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at . Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tulshibagwale-wimse-crest/.¶
Source for this draft and an issue tracker can be found at https://github.com/SGNL-ai/crest.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 May 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The REST architecture has been very successful and used almost universally in modern computing environments. However, it requires each request to carry the entire context of the request so that the server servicing the HTTP request can process it. A benefit of this approach is that each request from the same client can be serviced by different server-side instances, thereby making it easier to load-balance and provide better availability, reliability and response-time characteristics. As the amount of data in the context grows, this strategy, however, causes each request to be more expensive in terms of the network traffic and creates latency of its own.¶
The Contextualized REST (CREST) architecture addresses this by enabling HTTP servers to cache independently addressed context items. One or more server-side instances can share the same cache, making it more efficient than carrying the context with each request. At the same time, the CREST architecture enables different collections of server-side instances to have different caches. This enables geographically or network separated instances to maintain different caches.¶
The Context Cache (CC) is an abstraction that assumes one or more server side components can access a cache which can hold context across requests.¶
The CC is organized as a collection of independent items. Each item can be created, read, updated and deleted independently. Items may expire at any time. Each Item is identified by a unique identifier called CCII (Context Cache Item Identifier). The CCII format is a Base64 encoded with URL and Filename Safe Alphabet as described in RFC4648 [RFC4648].¶
When a client wants to make a request by referencing a CC Item, it includes a header named CCII in the request. The value of this header is a comma separated list of CCIIs.¶
CCII ccii1, ccii2, ccii3
A contextualized REST HTTP Request includes exactly one CCII header Section 3 that references the Context Cache Items that it depends upon.¶
If the HTTP server is unable to find the Context Cache Item referenced in a CREST Request Section 4, it MUST return the status code 424 (Failed Dependency) to the HTTP client. The body of the HTTP response SHOULD contain the MISSED-CCII header. The value of this header MUST be a comma separated list of one or more items that were not found in the cache.¶
MISSED-CCII ccii1, ccii2
A HTTP client MAY create or delete a CC Item. These operations are done by including specific headers in the HTTP request and obtaining specific headers in the HTTP response.¶
To create a CC Item, the HTTP client includes the request header named CC-CreateItems. The value of the CC-CreateItems header is a comma separated list of URL Safe Base64 [RFC4648] encoding of the values to be inserted into the CC. If zero or more of the specified values already exist in the CC or if the HTTP server creates one or more of the specified values in the CC, it includes the CCII header in the response, and sets its value to the CCII of the item specified in the request.¶
The HTTP client MUST accept the CCII headers in all responses with status codes except responses that have the status codes greater than 499.¶
CC-CreateItems abc123-efg456_,789hij_012,asdkflkau3
CCII ccii3,ccii4
To delete a CC Item, the HTTP client includes the request header named CC-DeleteItems. The value of the CC-DeleteItems header is a comma separated list of CCIIs. The HTTP Server MAY delete the requested CC Items. The HTTP Server confirms the deletion by including a Deleted-CCII header in the HTTP response.¶
CC-DeleteItems ccii1,ccii3
Deleted-CCII ccii1
This is a non-normative section.¶
The CREST architecture enables a pool of HTTP server components to share a cache and a request received at any one in the pool to reference the cache. This can be achieved in today's computing environments within the limits of a VPC or a data center.¶
Since most client requests would route to the same data center, this strategy can provide improved efficiency over the requirement to pass the entire context with each request.¶