REST Beginnings Architectural Styles and the Design of Network-based Software Architectures by Roy Fielding (2000)Ph.D. DissertationIntroduction to the Representational State Transfer(REST) architectural style for distributedhypermedia systems, describing the softwareengineering principles guiding REST and theinteraction constraints chosen to retain thoseprinciples…..Discusses Network-based Application ArchitecturalStyles with five additional styles discussed inChapter 3.
Why REST? | What is REST? REST attempts to minimize latency while maximizing scalability. REST is a Style REST is a set of six constraints (one optional – really 10) An API is NOT RESTful if it is not adhering to these constraints which is not necessarily a bad thing. While REST provides a number of benefits, it may not be the right Architectural Style for a given project What are the common misconceptions
Common MisconceptionsREST is NOT: URIs Identifying Resources Designing Responses (XML, JSON, XHTML, HAL) HTTP Verbs (GET, PUT, POST, DELETE,….) Headers (Caching) HTTP Response Codes
Client-ServerSeparation of concerns is the principle behind theclient-server constraints. By separating the userinterface concerns from the data storage concerns,we improve the portability of the user interfaceacross multiple platforms and improve scalability bysimplifying the server components. Perhaps mostsignificant to the Web, however, is that theseparation allows the components to evolveindependently, thus supporting the Internet-scalerequirement of multiple organizational domains.
StatelessThe client–server communication is furtherconstrained by no client context being stored on theserver between requests. Each request from anyclient contains all of the information necessary toservice the request, and any session state is held inthe client.This constraint induces the properties of visibility,reliability, and scalability.Like most architectural choices, the statelessconstraint reflects a design trade-off.
CacheAs on the World Wide Web, clients can cacheresponses. Responses must therefore, implicitly orexplicitly, define themselves as cacheable, or not,to prevent clients reusing stale or inappropriatedata in response to further requests. Well-managedcaching partially or completely eliminates someclient–server interactions, further improvingscalability and performance.The advantage of adding cache constraints is thatthey have the potential to partially or completelyeliminate some interactions, improving efficiency,scalability, and user-perceived performance byreducing the average latency.
Uniform InterfaceThe central feature that distinguishes the RESTarchitectural style from other network-based stylesis its emphasis on a uniform interface betweencomponents.Implementations are decoupled from the servicesthey provide, which encourages independentevolvability.REST is further defined by four interfaceconstraints: identification of resources;manipulation of resources through representations;self-descriptive messages; and, hypermedia as theengine of application state.
Layered SystemsA client cannot ordinarily tell whether it is connecteddirectly to the end server, or to an intermediaryalong the way. Intermediary servers may improvesystem scalability by enabling load-balancing andby providing shared caches. They may also enforcesecurity policies.The primary disadvantage of layered systems isthat they add overhead and latency to theprocessing of data.Layers can be used to encapsulate legacy servicesand to protect new services from legacy clients,simplifying components by moving infrequentlyused functionality to a shared intermediary
Code on demand (optional)The final addition to our constraint set for RESTcomes from the code-on-demand style.REST allows client functionality to be extended bydownloading and executing code in the form ofapplets or scripts.This simplifies clients by reducing the number offeatures required to be pre-implemented. Allowingfeatures to be downloaded after deploymentimproves system extensibility.An optional constraint allows us to design anarchitecture that supports the desired behavior inthe general case, but with the understanding that itmay be disabled within some contexts.
REST Architectural ConstraintsIf a service violates any of the required constraints,it cannot be considered RESTful.Complying with these constraints, and thusconforming to the REST architectural-style, enablesany kind of distributed hypermedia system to havedesirable emergent properties, such asperformance, scalability, simplicity, modifiability,visibility, portability, and reliability.
REST Sub-Constraints Identified as the "four interface constraints“ and areonly partially identified in the original text. Identification of Resources Manipulation of Resources throughRepresentations Self-Descriptive Messages Hypermedia as the Engine of Application State(HATEOAS )Much later (2008) Fielding published a blog tofurther define the Hypermedia Constraint: REST APIs must be hypertext driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-718
REST Sub-Constraints Hypermedia as the Engine of Application StateA REST API should be entered with no prior knowledge beyond theinitial URI (bookmark) and set of standardized media types thatare appropriate for the intended audience (i.e., expected to beunderstood by any client that might use the API). From that pointon, all application state transitions must be driven by clientselection of server-provided choices that are present in thereceived representations or implied by the user’s manipulation ofthose representations. The transitions may be determined (orlimited by) the client’s knowledge of media types and resourcecommunication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand).
REST Architectural ElementsThe Representational State Transfer (REST) styleis an abstraction of the architectural elementswithin a distributed hypermedia system.REST ignores the details of componentimplementation and protocol syntax in order tofocus on:- the roles of components,- the constraints upon their interaction with othercomponents, - their interpretation of significant dataelements.REST encompasses the fundamental constraintsupon components, connectors, and data that definethe basis of the Web architecture, and thus theessence of its behavior as a network-basedapplication.
REST from a Different Angle Richardson Maturity Model (RMM) Level 3 Level 2 + Hypermedia RESTful Services Level 2 Many URIs, many verbs CRUD services (e.g. Amazon S3) Level 1 URI Tunneling Many URIs, Single verb Level 0 SOAP, XML(POX), RPC Single URI
Conclusions RPC URI-Tunneling are the worst approach when comparing benefits/effort ratio Start-up cost of HTTP-based Type I APIs is actually smaller than RPC URI-Tunneling, mostly because the former leverages HTTP mechanisms (methods, failure model, caching) Depending on the degree to which existing media types apply to the problem domain HTTP-based Type II should be considered over HTTP- based Type I because the start-up cost is almost identical.If you are to any degree concerned with long term maintenance- andevolution cost REST is the best solution despite the start-up cost.
References Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf Implementing Rest https://code.google.com/p/implementing-rest/ Mike Amundsen Blog/Articles http://www.amundsen.com/blog/ http://www.infoq.com/author/Mike-Amundsen Classification of HTTP-based APIs http://www.asp.net/web-api/overview ASP.NET Web API http://www.asp.net/web-api/overview Classification of HTTP-based APIs http://nordsc.com/ext/classification_of_http_based_apis.html Richardson Maturity Model http://martinfowler.com/articles/richardsonMaturityModel.html