REST-based Distributed-System Pattern: Difference between revisions

From GM-RKB
Jump to navigation Jump to search
m (Text replacement - "\. \s+([A-Z][a-z][a-z])" to ". $1")
m (Text replacement - "]]s **" to "]]s. **")
 
Line 35: Line 35:
*** Encourage the use of [[SELF-DESCRIPTIVE message]]s through:
*** Encourage the use of [[SELF-DESCRIPTIVE message]]s through:
**** Clear separation between [[control-data]] ([[HTTP Header]]s) and [[message bodi]]es
**** Clear separation between [[control-data]] ([[HTTP Header]]s) and [[message bodi]]es
**** [[Dependence]] (and ease of use) on [[media-type]]s
**** [[Dependence]] (and ease of use) on [[media-type]]s.
**** Full and easy control of [[caching directive]]s (including automatic marking of GET responses based on configuration information)  
**** Full and easy control of [[caching directive]]s (including automatic marking of GET responses based on configuration information)  
*** Encourage implementing resources as REPRESENTATIONS (using media-types to express resource representations) through:
*** 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
**** Ability to mark resources and methods as supportive of one or more media types
**** Easy access to [[data serialization|serialization]]/[[transformation of resource data]] into [[media-type compliant representation]]s
**** Easy access to [[data serialization|serialization]]/[[transformation of resource data]] into [[media-type compliant representation]]s.
**** 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)  
**** 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 IDENTIFIER]]S (using [[URI mapping]] to match [[request URI]]s to [[server-side code]])
*** Encourage implementing [[RESOURCE IDENTIFIER]]S (using [[URI mapping]] to match [[request URI]]s to [[server-side code]])

Latest revision as of 15:36, 24 July 2023

A REST-based Distributed-System Pattern is a stateless client-server Distributed-System Pattern with Cacheable systems, Layered systems, and Uniform Interfaces



References

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.[1] The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine.[1] 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.
  1. Jump up to: 1.0 1.1 Chapter 5 of Fielding's dissertation is "Representational State Transfer (REST)".