The Contextualized REST Architecture
draft-tulshibagwale-wimse-crest-00

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,
              <https://www.rfc-editor.org/rfc/rfc4648>.

7.2.  Informative References

   [REST]     Fielding, R. T., "Representational State Transfer (REST)",
              n.d., <https://ics.uci.edu/~fielding/pubs/dissertation/
              rest_arch_style.htm>.

   [SPIFFE]   Cloud Native Computing Foundation, "Secure Production
              Identity Framework for Everyone", n.d.,
              <https://spiffe.io/docs/latest/spiffe-about/overview/>.

   [TRATS]    Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-oauth-
              transaction-tokens/>.

Acknowledgements

Author's Address

   Atul Tulshibagwale
   SGNL
   Email: atul@sgnl.ai

Tulshibagwale              Expires 25 May 2025                  [Page 6]