Successfully reported this slideshow.

Rest and the hypermedia constraint

7

Share

Loading in …3
×
1 of 66
1 of 66

Rest and the hypermedia constraint

7

Share

Download to read offline

A RESTful API is only truly RESTful if it uses hypermedia to tell us about all the actions that can be performed on the curent resource, allowing us to traverse the API from a single entry point.

His session looks at REST and HATEOAS (Hypermedia As The Engine Of Application State) to illustrate good service structure. Ben will use the RESTful file sharing service fdrop.it to illustrate the various examples of how this can be used.

This session is recommended for architects and senior developers alike and will give a good grounding in writing excellent, self-explanatory RESTful services.

A RESTful API is only truly RESTful if it uses hypermedia to tell us about all the actions that can be performed on the curent resource, allowing us to traverse the API from a single entry point.

His session looks at REST and HATEOAS (Hypermedia As The Engine Of Application State) to illustrate good service structure. Ben will use the RESTful file sharing service fdrop.it to illustrate the various examples of how this can be used.

This session is recommended for architects and senior developers alike and will give a good grounding in writing excellent, self-explanatory RESTful services.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Rest and the hypermedia constraint

  1. 1. REST and HATEOAS Ben Longden, PHPNW 2011
  2. 2. REST and the Hypermedia Constraint Ben Longden, PHPNW 2011
  3. 3. Who are you?
  4. 4. Who are you? @blongden
  5. 5. Who are you?
  6. 6. Who are you? @ibuildings
  7. 7. Who are you?
  8. 8. Who are you? @fdrop
  9. 9. REST REpresentational State Transfer
  10. 10. REST Series of constraints for distributed hypermedia systems - Roy Fielding, 2000
  11. 11. Constraints are good
  12. 12. Constraints are good They (help) stop you from doing crazy things
  13. 13. REST is an Architecture It is not a protocol
  14. 14. Goals Scalability Generality of Interfaces Independent deployment of components Intermediaries to reduce latency, enforce security, and encapsulate legacy systems.
  15. 15. Client server
  16. 16. Stateless
  17. 17. Cache
  18. 18. Layered system
  19. 19. Code on demand
  20. 20. Uniform interface
  21. 21. Uniform interface Identification of resources
  22. 22. Uniform interface Manipulations of resources through representations
  23. 23. Uniform interface Self descriptive messages
  24. 24. Uniform interface Hypertext as the engine of application state
  25. 25. The hypermedia constraint?
  26. 26. The hypermedia constraint A URI request returns all valid state changes
  27. 27. The hypermedia constraint It’s how the web works
  28. 28. The hypermedia constraint You already understand it!
  29. 29. HTTP
  30. 30. HTTP Your browser speaks the language of text/html
  31. 31. <!DOCTYPE html>
  32. 32. HTML Using hypermedia on the web, you can link to different types of data
  33. 33. HTML Using hypermedia on the web, you can link to different types of data text/css image/png audio/mpeg
  34. 34. Hypermedia Types “Hypermedia Types are MIME media types that contain native hyper-linking semantics that induce application flow.” - Mike Amundsen (2010)
  35. 35. The hypermedia constraint The client tells the server what language it speaks
  36. 36. The hypermedia constraint The server tells the client what to do
  37. 37. HTTP/1.1
  38. 38. HTTP/1.1 HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT PATCH
  39. 39. GET and POST is OK
  40. 40. GET and POST is OK REST doesn’t care what methods you use
  41. 41. GET and POST is OK HTTP cares that the methods are used correctly
  42. 42. Life in XHTML The website is also the API
  43. 43. Life in XHTML Inconvenient and difficult to maintain
  44. 44. False start #1 Attempt a custom hypermedia type
  45. 45. False start #2 application/atom+xml
  46. 46. False start #3 application/xhtml+xml
  47. 47. Custom hypermedia types Consider registered types first
  48. 48. Custom hypermedia types More likely to be understood
  49. 49. A solution application/vnd.fdrop.xhtml+xml
  50. 50. A solution XHTML has hypermedia controls built in
  51. 51. A solution Contains most of what I need
  52. 52. XML based media types Namespaces
  53. 53. Let’s see it then! @RESTConsole
  54. 54. What about JSON? application/vnd.collection+json application/hal+json
  55. 55. Versioning http://www.w3.org/History/19921103- hypertext/hypertext/WWW/TheProject.html
  56. 56. Versioning The server makes no assumptions on the capabilities of the client
  57. 57. Versioning If the client does not support something, it simply ignores it
  58. 58. Versioning The web is not versioned
  59. 59. Versioning Correct use of hypermedia means you can change things without affecting clients
  60. 60. Versioning But if you must...
  61. 61. Versioning Accept: application/vnd.fdrop.v2.xhtml+xml
  62. 62. http://tools.ietf.org/html/rfc2616 http://tools.ietf.org/html/rfc4287 http://amundsen.com/hypermedia/ http://amundsen.com/media-types/collection/ http://www.flickr.com/photos/bjornmeansbear/4727475559/
  63. 63. http://joind.in/talk/view/3589 @blongden

Editor's Notes

  • \n
  • \n
  • Developer for 20 years\nProfessional developer since 2002\nStarted on C, C++ and Perl\nFocussed on Perl and moved into web app development where I picked up PHP\nmobile web, standards and software architectures\n
  • Technical Team Lead since the start of 2010\nOne of the Sheffield office founders\n
  • Sole developer of fdrop.it\nCreated to solve my problem of &amp;#x2018;why is it so difficult to send a file to someone online?&amp;#x2019;\n
  • \n
  • \n
  • Doctoral Dissertation\n&amp;#x2018;Architectural Styles and the Design of Network-based Software Architectures&amp;#x2019;\n\none of the principle author of HTTP specification (RFC 1945/2616)\nIn 1999 he was named my MIT Technology Review as one of the top 100 innovators in the world under 35\n\n\n
  • \n
  • Constraints help to guide the creative project\n\nSacrifice is usually made retroactively\n
  • Can be applied to ANY distributed system\nWeb application or API design\n
  • \n
  • Clients not concerned about data storage\nServers not concerned about the user interface or user state\ncomponents evolve independently if interface remains constant\n
  • Each request from the client must contain ALL of the information required\nCannot rely on stored context on the server\nSession state on the client\nVisibility (Server can be observed at any time), Reliability (network failure), Scalability (easy to add servers)\n
  • Responses must implicitly or explicitly define themselves as cacheable or not\nFurther improves scalability and performance\n\n
  • Client connected to the end server or to an intermediary along the way.\nLoad Balancers\nSecurity Policies at a Firewall\nReverse Proxy Cache\n\n
  • Service can temporarily extend client side functionality by providing code it can execute \nie, Javascript or java applets\n\nTHE OPTIONAL CONSTRAINT!\n
  • Four guiding principles to simplify architecture\n
  • On the web we use URI&amp;#x2019;s\n\nResources themselves are usually different to what is returned to the client\nUsually, a database resource will be represented in JSON or XML\n
  • When a client holds a representation, it is enough to be able to modify or delete the resource assuming the user has permission to do so\n
  • Each message describes itself. This means using an explicit mime type, and explicitly if the resource can be cached.\n
  • Clients make state transitions ONLY through links returned within the resource (ie, anchors in html)\n\nOnly exception is the entry point\n
  • HATEOAS is a horrible acronym\n
  • Using hypermedia (anchor, xlink, etc)\n
  • and it&amp;#x2019;s why it&amp;#x2019;s been so successful over the last 20 years. The web is 20 years old. That&amp;#x2019;s amazing - and because of standards and hypermedia, I can still reference things from 20 years ago.\n
  • A web page contains all the information within it to allow the user to move from the current state, to the next.\n
  • All types of HTML\nXHTML\n\nVersions within them are identified by the content (DOCTYPE, html tag or xml header)\nXML documents not processed as XML (no checks for well formedness)\n \n
  • HTML 5 won over XHTML for who gains supremacy over the browsers - HTML contains some really good stuff about describing text, images, user input etc and what HTTP function to use on them (ie, GET image, POST a form).\n
  • This is how you declare an html 5 document. It&amp;#x2019;s great for the web as browsers only need to understand GET and POST - this is fine and it&amp;#x2019;s still RESTful, but what if we need a representation of a resource that can support other actions?\n
  • \n
  • HTML is a hypermedia type\nXML is not\n
  • Accept header in HTTP\n
  • HTTP headers and Hypermedia!\n
  • \nHTTP 1.1 defines these 9 methods. HTML lets us use 2 of them. \n
  • That&amp;#x2019;s all you get in a browser\n\n
  • \n
  • GET to retrive, POST to create, PUT to update, DELETE\nPOST to a job queue to update and delete\nThese are HTTP, not REST (REST just defines the uniform interface)\n
  • API for free?\nDownsides\nSome actions need to be different over an API due to different UI\nAJAX\n
  • Focus on the UI breaks the API\n
  • Craft my own XML doc\nNeed to define my media type first\nToo much like work...\n
  • There was merit to this - which i&amp;#x2019;ll come back to\n
  • Remove the markup from the XHTML that was only there to layout the UI\nServe HTML5 to browsers on text/html!\nClose - but webkit on iOS and Android devices prefer XML\n
  • \n
  • \n
  • XHTML still in the media type so still self describing\nWont conflict with browsers\n\n
  • \n\n
  • form, input, img, a\nBrowsers already understand XHTML\nEasy for people to consume using any XML Reader\nDEMO\n
  • XHTML only supports GET and POST\nWhat if we need more?\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • ×