Separating REST Facts from Fallacies

5,991 views

Published on

This is my presentation for DDD7 on 22nd November 2008.

Published in: Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,991
On SlideShare
0
From Embeds
0
Number of Embeds
247
Actions
Shares
0
Downloads
138
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide
  • Separating REST Facts from Fallacies

    1. 1. Alan Dean
    2. 2. The Web <ul><li>Fallacy </li></ul><ul><ul><li>REST is just The Web </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>Much / most of the Web is not RESTful </li></ul></ul><ul><ul><li>REST was described, a posteriori, by Roy Fielding in his doctoral thesis as the architectural principles underlying HTTP (edited by Fielding et al ) </li></ul></ul><ul><ul><ul><li>http://www.ics.uci.edu/~fielding/pubs/dissertation/ </li></ul></ul></ul><ul><ul><li>REST is The Web done right </li></ul></ul>
    3. 3. Authoritative <ul><li>Fallacy </li></ul><ul><ul><li>REST is a matter of opinion </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>REST is what Roy says it is </li></ul></ul>
    4. 4. REST is an Architectural Style <ul><li>An architectural style is a coordinated set of architectural constraints that restricts the roles and features of architectural elements, and the allowed relationships among those elements, within any architecture that conforms to that style. </li></ul><ul><ul><li>A style can be applied to many architectures. </li></ul></ul><ul><ul><li>An architecture can consist of many styles. </li></ul></ul>
    5. 5. Deriving REST <ul><li>Style = nil </li></ul><ul><li>Style += Client/Server </li></ul><ul><li>Style += Stateless </li></ul><ul><li>Style += Caching </li></ul><ul><li>Style += Uniform Interface </li></ul><ul><li>Style += Layered System </li></ul><ul><li>Style += Code on Demand </li></ul>
    6. 6. Style = nil <ul><li>Starting from a condition of no constraints… </li></ul>
    7. 7. Style += Client/Server <ul><li>Apply separation of concerns </li></ul>improves UI portability simplifies server enables multiple organizational domains
    8. 8. REST & HTTP <ul><li>Fallacy </li></ul><ul><ul><li>REST == HTTP </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>“ Good grief. Why does everyone equate REST with HTTP? REST apps work quite well with file, ftp, gopher, wais, urn, ... I won't even mention waka in that list because it isn't done yet.” </li></ul></ul><ul><ul><ul><li>(Roy Fielding) </li></ul></ul></ul><ul><ul><li>HTTP is simply the best known Transfer protocol </li></ul></ul>
    9. 9. Style += Stateless <ul><li>Constrain interaction to be stateless </li></ul>simplifies server improves scalability improves reliability degrades efficiency
    10. 10. Stateless <ul><li>It is important to differentiate (client) application state from (server) resource state </li></ul><ul><li>Fallacy </li></ul><ul><ul><li>You can do an end-around of the stateless constraint by turning application state into resource state </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>The server should have no knowledge about application state </li></ul></ul><ul><ul><li>The client is free to use a different server to persist application state </li></ul></ul>
    11. 11. Style += Caching <ul><li>Add optional non-shared caching </li></ul>reduces average latency improves efficiency improves scalability degrades reliability $ $
    12. 12. Style += Uniform Interface <ul><li>Apply generality </li></ul>degrades efficiency improves visibility independent evolvability decouples implementation $ $ $
    13. 13. Uniform Interface <ul><li>Uniform identification of resources </li></ul><ul><li>Uniform access methods </li></ul><ul><ul><li>Universal semantics </li></ul></ul><ul><li>Manipulation of resources through the exchange of representations </li></ul><ul><li>Self-descriptive messages </li></ul><ul><li>Hypermedia / hypertext as the engine of application state </li></ul>
    14. 14. Uniform identification of resources <ul><li>All important resources are identified by one (uniform) resource identifier mechanism, e.g. a URI </li></ul><ul><li>Fallacy </li></ul><ul><ul><li>The layout of the URI is important to REST </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>The layout of the URI is opaque to REST </li></ul></ul><ul><ul><li>A ‘human-friendly’ URI is good, regardless </li></ul></ul>
    15. 15. Uniform access methods <ul><li>Actions mean the same for all resources </li></ul><ul><li>Fallacies </li></ul><ul><ul><li>Methods IN { PUT, GET, POST, DELETE } </li></ul></ul><ul><ul><li>Therefore, REST == CRUD </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>Any universally understood representation action can be used, e.g.: </li></ul></ul><ul><ul><ul><li>WebDAV LINK or PATCH but not PROP </li></ul></ul></ul><ul><ul><ul><li>COM IDispatch and IUnknown can be regarded as uniform COM object ‘GET’ access methods </li></ul></ul></ul><ul><ul><li>Some HTTP methods are insufficiently defined </li></ul></ul><ul><ul><ul><li>Yes, I’m talking “POST” aka “MISCELLANEOUS” </li></ul></ul></ul>
    16. 16. Hypermedia / hypertext as the engine of application state <ul><li>Often abbreviated to HATEOAS </li></ul><ul><li>Think about media-types </li></ul><ul><li>Fallacies </li></ul><ul><ul><li>Hypertext == HTML </li></ul></ul><ul><ul><li>Atom everywhere </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>Explicit or implicit links support HATEOAS </li></ul></ul><ul><ul><li>Links exist in non-HTML media-types </li></ul></ul><ul><ul><li>There are more media types than just HTML and Atom </li></ul></ul>
    17. 17. Roy Fielding on HATEOS <ul><li>“ A truly RESTful API looks like hypertext. </li></ul><ul><li>Every addressable unit of information carries an address , either explicitly (e.g., link and id attributes) or implicitly (e.g., derived from the media type definition and representation structure). </li></ul><ul><li>Query results are represented by a list of links with summary information , not by arrays of object representations (query is not a substitute for identification of resources). </li></ul><ul><li>Resource representations are self-descriptive : the client does not need to know if a resource [belongs to a specific website] because it is just acting on the representations received.” </li></ul>
    18. 18. Style += Layered System <ul><li>Apply information hiding </li></ul>shared caching improves scalability adds latency simplifies client legacy encapsulation load balancing $ $ $ $ $ $ $ $ $
    19. 19. Style += Code on Demand <ul><li>Allow code-on-demand (applets/js) </li></ul>simplifies clients reduces visibility improves extensibility $ $ $ $ $ $ $ $ $ .js
    20. 20. Simplicity <ul><li>Fallacy </li></ul><ul><ul><li>REST is simple </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>REST has simple constraints </li></ul></ul><ul><ul><li>RESTful systems are often complex in their collaborations </li></ul></ul><ul><ul><li>Truly RESTful system design is non-trivial </li></ul></ul>
    21. 21. Difficulty <ul><li>Fallacy </li></ul><ul><ul><li>REST is easy </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>All distributed system development is hard </li></ul></ul><ul><ul><ul><li>http://wikipedia.org/wiki/Fallacies_of_Distributed_Computing </li></ul></ul></ul><ul><ul><li>REST is not a panacea </li></ul></ul>
    22. 22. Plain Old XML (POX) <ul><li>Fallacy </li></ul><ul><ul><li>REST is just POX-over-HTTP </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>POX (as generally understood) is typically an RPC style </li></ul></ul><ul><ul><li>POX typically tunnels through HTTP using POST </li></ul></ul><ul><ul><ul><li>With endpoints that look & act like methods </li></ul></ul></ul><ul><ul><ul><li>Without meeting the constraints of REST </li></ul></ul></ul><ul><ul><ul><li>Content-Type: application/xml is a tell </li></ul></ul></ul>
    23. 23. hi-REST / lo-REST <ul><li>Fallacy </li></ul><ul><ul><li>The hi-REST / lo-REST meme </li></ul></ul><ul><ul><ul><li>Started by Don Box </li></ul></ul></ul><ul><li>Fact </li></ul><ul><ul><li>“ REST, as styles go, is more like the architecture of barnyards and office suites. The notion that there is anything lo or hi about it demonstrates a fundamental lack of understanding” </li></ul></ul><ul><ul><ul><li>(Roy Fielding) </li></ul></ul></ul><ul><ul><li>You are either RESTful, or not </li></ul></ul><ul><ul><ul><li>You become RESTful by not breaching any constraint </li></ul></ul></ul>
    24. 24. SOAP Services (WS-*) <ul><li>Fallacies </li></ul><ul><ul><li>Commit to REST or WS-* </li></ul></ul><ul><ul><li>REST is the ‘ultimate architecture’ </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>WS-* is not an architectural style </li></ul></ul><ul><ul><ul><li>SOA == REST nil style </li></ul></ul></ul><ul><ul><li>REST is not a protocol stack </li></ul></ul><ul><ul><li>REST is appropriate when a Resource Oriented Architecture (ROA) is desirable </li></ul></ul><ul><ul><li>A system can compose both REST and WS-* </li></ul></ul><ul><ul><li>We are in a world where some architects still think you need to commit to one or the other </li></ul></ul>
    25. 25. Standardization <ul><li>Fallacy </li></ul><ul><ul><li>Unlike WS-*, REST has no standards </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>Hymermedia / hypertext is standardized </li></ul></ul><ul><ul><ul><li>fewer UIs </li></ul></ul></ul><ul><ul><li>Identification is standardized </li></ul></ul><ul><ul><ul><li>less communication </li></ul></ul></ul><ul><ul><li>Exchange protocols are standardized </li></ul></ul><ul><ul><ul><li>fewer integrations </li></ul></ul></ul><ul><ul><li>Interactions are standardized </li></ul></ul><ul><ul><ul><li>fewer semantics </li></ul></ul></ul><ul><ul><li>Media-types are standardized </li></ul></ul><ul><ul><ul><li>fewer translations </li></ul></ul></ul>
    26. 26. Man –vs- Machine <ul><li>Fallacy </li></ul><ul><ul><li>RESTful systems are only good for systems which require human interaction, like web pages </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>A well-written RESTful application protocol will sufficiently remove ambiguity to allow machine-to-machine interaction </li></ul></ul><ul><ul><ul><li>AtomPub achieves this </li></ul></ul></ul><ul><ul><ul><li>RSS is the counter-example </li></ul></ul></ul>
    27. 27. Interface Definitions <ul><li>Fallacy </li></ul><ul><ul><li>REST needs a WSDL such as WADL </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>The whole point of the Uniform Interface constraint is to remove the need for specialised interface definitions </li></ul></ul>
    28. 28. Authentication <ul><li>Fallacy </li></ul><ul><ul><li>It’s OK to use server cookies to authenticate users in REST </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>“ Authentication is orthogonal. Cookies are also orthogonal when they are simply used for content negotiation or authentication. However, Cookie authentication is not allowed in REST because it lacks visibility, which causes security problems […]” </li></ul></ul><ul><ul><ul><li>(Roy Fielding) </li></ul></ul></ul><ul><ul><li>For HTTP, use WWW-Authenticate </li></ul></ul>
    29. 29. Scalability <ul><li>Fallacy </li></ul><ul><ul><li>RESTful services always scale well </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>Not unless you have implemented caching </li></ul></ul><ul><ul><li>Not if interaction requires access control </li></ul></ul>
    30. 30. Transactions <ul><li>Fallacy </li></ul><ul><ul><li>You can’t do transactions in REST </li></ul></ul><ul><li>Facts </li></ul><ul><ul><li>You can do atomic server transactions within the bounds of a single HTTP request </li></ul></ul><ul><ul><li>You can do compensatory ‘long-running’ and distributed transactions across multiple HTTP requests provided that you don’t break the Layered System constraint </li></ul></ul>
    31. 31. Tools <ul><li>Fallacy </li></ul><ul><ul><li>REST needs more tooling before adoption </li></ul></ul><ul><li>Fact </li></ul><ul><ul><li>The tooling to implement REST on HTTP already exists </li></ul></ul><ul><ul><ul><li>However, developers need to throw off their current mindset and understand REST </li></ul></ul></ul><ul><ul><li>The on-ramp to REST can be made easier with better tools </li></ul></ul><ul><ul><ul><li>ASP.NET MVC is superior to ASP.NET WebForms </li></ul></ul></ul>
    32. 32. Adoption <ul><li>Facts </li></ul><ul><ul><li>Many systems could benefit by adopting a RESTful architecture </li></ul></ul><ul><ul><li>Acceptance and adoption has been slow </li></ul></ul><ul><ul><ul><li>This is now changing </li></ul></ul></ul><ul><ul><ul><li>Beware of the gloryhounds who follow buzzwords but don’t actually grok REST </li></ul></ul></ul><ul><ul><ul><ul><li>Do you ETag? </li></ul></ul></ul></ul><ul><ul><li>REST is not easy to learn, especially when a previous mindset needs to be set aside </li></ul></ul><ul><ul><li>Too many sites wrongly claim a RESTful API </li></ul></ul>
    33. 34. </presentation> <ul><li>Email </li></ul><ul><li>[email_address] </li></ul><ul><li>Links </li></ul><ul><li>http://delicious.com/alan.dean/rest </li></ul><ul><li>http://alandean.blogspot.com </li></ul><ul><li>http://twitter.com/adean </li></ul><ul><li>Acknowledgements </li></ul><ul><li>“ A little REST and Relaxation” </li></ul><ul><li>Roy Fielding, 2007 ApacheCon </li></ul>

    ×