REST-based Distributed-System Pattern

A REST Distributed-System Pattern is a Distributed-System Pattern based on Client–server model, Stateless protocols, Cacheable systems, Layered systems, and Uniform Interfaces

• AKA: Representational State Transfer.
• Context:
  • It can be supported by a REST Framework, such as Django REST Framework.
• Counter-Example(s):
  • an RPC Distributed-System Pattern, such as CORBA.
• See: Hypermedia, Hypertext Transfer Protocol, Web Services, SOAP, *RESTful Service Description Language, Create, read, update and delete, Hypermedia as the Engine of Application State, Resource-oriented architecture, Service-oriented architecture, Resource-oriented computing, Domain Application Protocol.

---

---

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)

---