REST-based Distributed-System Pattern

A REST-based Distributed-System Pattern is a stateless client-server web service architectural pattern that can support REST-based distributed systems through uniform interface constraints, cacheable interactions, and layered system architectures.

• AKA: Representational State Transfer Pattern, REST Architectural Pattern, RESTful Pattern.
• Context:
  • It can typically enable Resource-Based Interaction through uniform resource identifiers and standardized HTTP methods.
  • It can typically support Stateless Communication through self-contained requests containing all necessary information.
  • It can typically implement Cacheable Response through HTTP cache directives and conditional requests.
  • It can typically provide Layered System Architecture through intermediary servers and load balancers.
  • It can typically enforce Uniform Interface Constraint through resource identification, resource manipulation, and self-descriptive messages.
  • ...
  • It can often enable Hypermedia-Driven Application State through hyperlinks and link relations.
  • It can often support Content Negotiation through media type specifications and accept headers.
  • It can often implement Idempotent Operation through safe HTTP methods and repeatable requests.
  • It can often provide Scalable Architecture through horizontal scaling and stateless design.
  • ...
  • It can range from being a Simple REST-based Distributed-System Pattern to being a Mature REST-based Distributed-System Pattern, depending on its REST maturity level.
  • It can range from being a Basic REST-based Distributed-System Pattern to being a Hypermedia-Driven REST-based Distributed-System Pattern, depending on its REST constraint adoption.
  • ...
  • It can integrate with HTTP Protocol for request-response communication.
  • It can leverage JSON Format for lightweight data interchange.
  • It can utilize OAuth 2.0 Protocol for secure authorization.
  • It can employ OpenAPI Specification for API documentation.
  • It can incorporate GraphQL Query Language for flexible data fetching.
  • ...
• Example(s):
  • REST-based Web Services, such as:
    • Public REST APIs, such as:
      • Twitter REST API for social media data access.
      • GitHub REST API for repository management operations.
      • Stripe REST API for payment processing services.
      • Google Maps REST API for geolocation services.
    • Enterprise REST Services, such as:
      • Salesforce REST API for CRM data integration.
      • AWS REST API for cloud resource management.
      • Azure REST API for Microsoft cloud services.
  • REST Framework Implementations, such as:
    • Python REST Frameworks, such as:
      • Django REST Framework for Django-based REST services.
      • FastAPI Framework for high-performance REST APIs.
      • Flask-RESTful Framework for lightweight REST services.
    • Java REST Frameworks, such as:
      • Spring REST Framework for Spring-based REST services.
      • JAX-RS Framework for Java EE REST implementations.
      • Jersey Framework for RESTful web services.
    • JavaScript REST Frameworks, such as:
      • Express.js REST Framework for Node.js REST services.
      • Hapi.js Framework for configuration-centric REST APIs.
      • Restify Framework for optimized REST services.
  • REST Maturity Levels, such as:
    • Level 0 REST Implementation using single URI endpoints.
    • Level 1 REST Implementation with resource-based URIs.
    • Level 2 REST Implementation with HTTP verb utilization.
    • Level 3 REST Implementation with hypermedia controls.
  • ...
• Counter-Example(s):
  • RPC-based Distributed-System Pattern, which uses remote procedure calls rather than resource-based interactions.
  • SOAP-based Web Service Pattern, which employs XML-based messaging protocols rather than REST constraints.
  • GraphQL API Pattern, which provides flexible query languages rather than fixed resource endpoints.
  • gRPC Pattern, which utilizes binary protocols rather than text-based HTTP communication.
  • WebSocket Pattern, which maintains persistent connections rather than stateless interactions.
• See: REST Framework, RESTful API, HTTP Protocol, Web Service Architecture, API Design Pattern, Microservices Architecture, Resource-Oriented Architecture, Richardson Maturity Model, HATEOAS Principle.

---

---

References

• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
• http://martinfowler.com/articles/richardsonMaturityModel.html

2013

• (Wikipedia, 2013) ⇒ http://en.wikipedia.org/wiki/representational_state_transfer Retrieved:2013-12-16.
  • Representational State Transfer (REST) is an architectural style consisting of a coordinated set of constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine. REST has been applied to describe desired web architecture, to identify existing problems, to compare alternative solutions, and to ensure that protocol extensions would not violate the core constraints that make the Web successful. Fielding used REST to design HTTP 1.1 and Uniform Resource Identifiers (URI). The REST architectural style is also applied to the development of Web services, as an alternative to other distributed-computing specifications such as SOAP.

• http://code.google.com/p/implementing-rest/wiki/RESTDevelopmentPrinciples
  • Development tools that enable a REST-style result:
    • Encourage application implementations as a collection of RESOURCES on a server (i.e. programming using a resource object)
    • Encourage the use of CACHING (making it easy to express and interpret caching directives for both client and server)
    • Encourage STATELESS interactions between client and server (making it hard to store transient state on the server, easy to store transient state on the client)
    • Encourage using a UNIFORM INTERFACE (with clearly defined semantics) for interacting with RESOURCES (programming using a limited set of public methods that follow protocol rules)
    • Encourage using a LAYERED SYSTEM as an implementation principle (making it easy to add authentication, caching, CDNs, etc. without re-writing existing code)
    • Encourage using CODE-ON-DEMAND to safely extend functionality at runtime (support servers sending scripts and plug-ins to clients, support accepting and executing plug-ins and scripts safely on the client)
  • In addition, the development environment should:
    • Encourage the use of SELF-DESCRIPTIVE messages through:
      • Clear separation between control-data (HTTP Headers) and message bodies
      • Dependence (and ease of use) on media-types.
      • Full and easy control of caching directives (including automatic marking of GET responses based on configuration information)
    • Encourage implementing resources as REPRESENTATIONS (using media-types to express resource representations) through:
      • Ability to mark resources and methods as supportive of one or more media types
      • Easy access to serialization/transformation of resource data into media-type compliant representations.
      • Ability to determine the beset match representation format (media type) for the client (e.g. support for server-driven and/or agent-driven content negotiation)
    • Encourage implementing RESOURCE IDENTIFIERS (using URI mapping to match request URIs to server-side code)
    • Encourage hypermedia to power application state (including mutually-agreed upon annotated links and link templates in the representations)

---