REST &  RESTful APIsThe State of Confusion
Why this topic? Not Well Understood ....consider how often we see software projects begin    with adoption of the latest...
REST Beginnings               Architectural Styles and       the Design of Network-based Software                    Archi...
Why REST? | What is REST? REST attempts to minimize latency while    maximizing scalability.   REST is a Style   REST i...
Common MisconceptionsREST is NOT: URIs Identifying Resources Designing Responses (XML, JSON, XHTML,  HAL) HTTP Verbs (...
REST Constraints Client-Server Stateless Cache Uniform Interface Layered System Code on Demand (only option constrai...
Client-ServerSeparation of concerns is the principle behind theclient-server constraints. By separating the userinterface ...
StatelessThe client–server communication is furtherconstrained by no client context being stored on theserver between requ...
CacheAs on the World Wide Web, clients can cacheresponses. Responses must therefore, implicitly orexplicitly, define thems...
Uniform InterfaceThe central feature that distinguishes the RESTarchitectural style from other network-based stylesis its ...
Layered SystemsA client cannot ordinarily tell whether it is connecteddirectly to the end server, or to an intermediaryalo...
Code on demand (optional)The final addition to our constraint set for RESTcomes from the code-on-demand style.REST allows ...
REST Architectural ConstraintsIf a service violates any of the required constraints,it cannot be considered RESTful.Comply...
REST Sub-Constraints Identified as the "four interface constraints“ and areonly partially identified in the original text....
REST Sub-Constraints   Hypermedia as the Engine of Application StateA REST API should be entered with no prior knowledge b...
REST Architectural ElementsThe Representational State Transfer (REST) styleis an abstraction of the architectural elements...
REST from a Different Angle      Richardson Maturity Model (RMM) Level 3    Level 2 + Hypermedia    RESTful Services L...
Conclusions RPC URI-Tunneling are the worst approach when comparing  benefits/effort ratio Start-up cost of HTTP-based T...
References Architectural Styles and the Design of Network-based Software  Architectures     http://www.ics.uci.edu/~fiel...
Upcoming SlideShare
Loading in …5
×

REST & RESTful APIs: The State of Confusion

3,952 views

Published on

REST & RESTful APIs, an attempt to clear up some of the confusion that exists when it comes to RESTful APIs.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,952
On SlideShare
0
From Embeds
0
Number of Embeds
1,155
Actions
Shares
0
Downloads
56
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

REST & RESTful APIs: The State of Confusion

  1. 1. REST & RESTful APIsThe State of Confusion
  2. 2. Why this topic? Not Well Understood ....consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by- buzzword is a common occurrence. At least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful. (Roy Fielding 2000) Where to start when designing a RESTful API REST & Language/Client (C#, Javascript, Browser, Devices) REST Encourages scalability REST Promotes Loose Coupling between Client & Server
  3. 3. 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.
  4. 4. 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
  5. 5. Common MisconceptionsREST is NOT: URIs Identifying Resources Designing Responses (XML, JSON, XHTML, HAL) HTTP Verbs (GET, PUT, POST, DELETE,….) Headers (Caching) HTTP Response Codes
  6. 6. REST Constraints Client-Server Stateless Cache Uniform Interface Layered System Code on Demand (only option constraint)
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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
  12. 12. 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.
  13. 13. 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.
  14. 14. 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
  15. 15. 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).
  16. 16. 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.
  17. 17. 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
  18. 18. 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.
  19. 19. 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

×