wimse A. Tulshibagwale Internet-Draft SGNL Intended status: Informational 21 November 2024 Expires: 25 May 2025 The Contextualized REST Architecture draft-tulshibagwale-wimse-crest-00 Abstract 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. Tulshibagwale Expires 25 May 2025 [Page 1] Internet-Draft crest November 2024 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. About This Document 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. Status of This Memo 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 Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Tulshibagwale Expires 25 May 2025 [Page 2] Internet-Draft crest November 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Context Cache . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Cached Items . . . . . . . . . . . . . . . . . . . . . . 4 3. CCII Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Contextualized REST HTTP Request . . . . . . . . . . . . . . 4 4.1. Cache Miss . . . . . . . . . . . . . . . . . . . . . . . 4 5. Context Cache Operations . . . . . . . . . . . . . . . . . . 5 5.1. Create CC Items . . . . . . . . . . . . . . . . . . . . . 5 5.2. Delete CC Items . . . . . . . . . . . . . . . . . . . . . 5 6. Architecture Notes . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. Tulshibagwale Expires 25 May 2025 [Page 3] Internet-Draft crest November 2024 2. The Context Cache 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. 2.1. Cached Items 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]. 3. CCII Header 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 Figure 1: Non-normative example of a CCII Request Header 4. Contextualized REST HTTP Request A contextualized REST HTTP Request includes exactly one CCII header Section 3 that references the Context Cache Items that it depends upon. 4.1. Cache Miss 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 Figure 2: Non-normative example of a MISSED-CCII Response Header Tulshibagwale Expires 25 May 2025 [Page 4] Internet-Draft crest November 2024 5. Context Cache Operations 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. 5.1. Create CC Items 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 Figure 3: Non-normative example of a CCII-CreateItem Request Header CCII ccii3,ccii4 Figure 4: Non-normative example of a CCII Response Header 5.2. Delete CC Items 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 Figure 5: Non-normative example of a CCII-DeleteItem Request Header Deleted-CCII ccii1 Figure 6: Non-normative example of a Deleted-CCII Response Header Tulshibagwale Expires 25 May 2025 [Page 5] Internet-Draft crest November 2024 6. Architecture Notes 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. 7. References 7.1. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . 7.2. Informative References [REST] Fielding, R. T., "Representational State Transfer (REST)", n.d., . [SPIFFE] Cloud Native Computing Foundation, "Secure Production Identity Framework for Everyone", n.d., . [TRATS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", n.d., . Acknowledgements Author's Address Atul Tulshibagwale SGNL Email: atul@sgnl.ai Tulshibagwale Expires 25 May 2025 [Page 6]