<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.tulshibagwale-wimse-crest" target="https://datatracker.ietf.org/doc/html/draft-tulshibagwale-wimse-crest-00">
   <front>
      <title>The Contextualized REST Architecture</title>
      <author initials="A." surname="Tulshibagwale" fullname="Atul Tulshibagwale">
         <organization>SGNL</organization>
      </author>
      <date month="November" day="21" year="2024" />
      <abstract>
	 <t>   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 &quot;session&quot; 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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-tulshibagwale-wimse-crest-00" />
   
</reference>
