Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Designing RESTful Web Services (APIdays2012 2012-12-04)

Designing RESTful Web Services (APIdays2012 2012-12-04)

Presentation given at API days 2012 in Paris, France.

David Zuelke

December 04, 2012
Tweet

More Decks by David Zuelke

Other Decks in Programming

Transcript

  1. DESIGNING HTTP INTERFACES
    AND RESTFUL WEB SERVICES

    View Slide

  2. DESIGNING
    RESTFUL WEB SERVICES

    View Slide

  3. David Zülke

    View Slide

  4. David Zuelke

    View Slide

  5. http://en.wikipedia.org/wiki/File:München_Panorama.JPG

    View Slide

  6. View Slide

  7. View Slide

  8. Founder

    View Slide

  9. View Slide

  10. @dzuelke

    View Slide

  11. ROY FIELDING
    Gave Us REST

    View Slide

  12. that was awesome

    View Slide

  13. because everyone could say

    View Slide

  14.  I haz REST nao

    View Slide

  15. when in fact

    View Slide

  16. they bloody didn’t

    View Slide

  17. REST
    What Does That Even Mean?

    View Slide

  18. REpresentational State Transfer

    View Slide

  19. Roy Thomas Fielding: Architectural styles and
    the design of network based software architectures.

    View Slide

  20. • Client-Server
    • Stateless
    • Cacheable
    • Layered System
    • Code on Demand (optional)
    • Uniform Interface
    REST CONSTRAINTS

    View Slide

  21. • A URL identifies a Resource
    • Methods perform operations on resources
    • The operation is implicit and not part of the URL
    • A hypermedia format is used to represent the data
    • Link relations are used to navigate a service
    UNIFORM INTERFACE

    View Slide

  22. a web page is not a resource

    View Slide

  23. it is a (complete) representation of a resource

    View Slide

  24. GET  /products/  HTTP/1.1
    Host:  acme.com
    Accept:  application/json
    HTTP/1.1  200  OK
    Content-­‐Type:  application/json;  charset=utf-­‐8
    Allow:  GET,  POST
    [
       {
           id:  1234,
           name:  "Red  Stapler",
           price:  3.14,
           location:  "http://acme.com/products/1234"
       }
    ]
    GETTING JSON BACK

    View Slide

  25. GET  /products/  HTTP/1.1
    Host:  acme.com
    Accept:  application/xml
    HTTP/1.1  200  OK
    Content-­‐Type:  application/xml;  charset=utf-­‐8
    Allow:  GET,  POST


       
           Red  Stapler
           3.14
       

    GETTING XML BACK

    View Slide

  26. but those are not hypermedia formats!

    View Slide

  27. (more on that a bit later)

    View Slide

  28. GET  /products/  HTTP/1.1
    Host:  acme.com
    Accept:  application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,*/*;q=0.5
    User-­‐Agent:  Mozilla/5.0  (Macintosh;  U;  Intel  Mac  OS  X  10_5_8;  en-­‐us)  AppleWebKit…
    HTTP/1.1  200  OK
    Content-­‐Type:  text/html;  charset=utf-­‐8
    Allow:  GET,  POST

       
           
           ACME  Inc.  Products
       
       
           Our  Incredible  Products
           
               Red  Stapler  (€3.14)
           
       

    AND FINALLY, HTML

    View Slide

  29. HERE’S A QUESTION FOR YOU
    What's the Biggest Reason for the Success of the Web?

    View Slide

  30. WWW

    View Slide

  31. first data exchange system

    View Slide

  32. planetary scale

    View Slide

  33. View Slide

  34. View Slide

  35. why is that possible?

    View Slide

  36. Hyperlinks!

    View Slide

  37. no tight coupling!

    View Slide

  38. loosely coupled by design

    View Slide

  39. no notification infrastructure

    View Slide

  40. HTTP/1.1 404 Not Found

    View Slide

  41. embraces failure

    View Slide

  42. more information != more friction

    View Slide

  43. no limits to scalability

    View Slide

  44. WWW is protocol-centric

    View Slide

  45. REST AND HYPERMEDIA
    RESTful Services with Hypermedia

    View Slide

  46. THE UNIFORM INTERFACE
    • Identification of Resources (e.g. through URIs)
    • Representations are conceptually separate!
    • Manipulation Through Representations (i.e. they are complete)
    • Self-Descriptive Messages (containing all information)
    • Hypermedia As The Engine Of Application State ("HATEOAS")
    magic awesomesauce essential to REST

    View Slide

  47. HATEOAS
    The Missing Piece in the Puzzle

    View Slide

  48. ONE LAST PIECE IS MISSING
    • How does a client know what to do with representations?
    • How do you go to the “next” operation?
    • What are the URLs for creating subordinate resources?
    • Where is the contract for the service?

    View Slide

  49. HYPERMEDIA AS THE ENGINE
    OF APPLICATION STATE
    • Use links to allow clients to discover locations and operations
    • Link relations are used to express the possible options
    • Clients do not need to know URLs, so they can change
    • The entire application workflow is abstracted, thus changeable
    • Hypermedia type has defined meanings for its contents
    • Communicating parties have common understanding of type

    View Slide

  50. application/xml

    View Slide

  51. soup of angle brackets with defined parsing rules

    View Slide

  52. application/json

    View Slide

  53. soup of curly braces with defined parsing rules

    View Slide

  54. those are merely serializations

    View Slide

  55. we need to attach semantics to the document contents

    View Slide

  56. (X)HTML and Atom are Hypermedia formats

    View Slide

  57. Or you roll your own...

    View Slide

  58. GET  /products/1234  HTTP/1.1
    Host:  acme.com
    Accept:  application/vnd.com.acme.shop+xml
    HTTP/1.1  200  OK
    Content-­‐Type:  application/vnd.come.acme.shop+xml;  charset=utf-­‐8
    Allow:  GET,  PUT,  DELETE


       1234
       Red  Stapler
       3.14
                                 href="http://acme.com/products/1234/payment"/>

    re-use Atom for
    link relations
    meaning defined in IANA Link Relations list
    A CUSTOM MEDIA TYPE
    Remind clients of
    Uniform Interface :)

    View Slide

  59. XML is really good for hypermedia formats

    View Slide

  60. (hyperlinks, namespaced attributes, re-use of formats, …)

    View Slide

  61. JSON is more difficult

    View Slide

  62. (no hyperlinks, no namespaces, no element attributes)

    View Slide



  63.    1234
       Red  Stapler
                                 href="http://acme.com/products/1234/payment"/>
       3.14

    {
       id:  1234,
       name:  "Red  Stapler",
       links:  [
           {
               rel:  "payment",
               type:  "application/vnd.com.acme.shop+json",
               href:  "http://acme.com/products/1234/payment"
           }
       ],
       price:  3.14
    }
    XML VERSUS JSON

    View Slide



  64.    1234
       Red  Stapler
                                 href="http://acme.com/products/1234/payment"/>
       3.14

    {
       id:  1234,
       name:  "Red  Stapler",
       links:  [
           {
               rel:  "payment",
               type:  "application/vnd.com.acme.shop+json",
               href:  "http://acme.com/products/1234/payment"
           }
       ],
       price:  {
           amount:  3.14,
           currency:  "EUR"
       }
    }
    XML VERSUS JSON
    Content (“node value”) still the same
    Float becomes object, stuff breaks

    View Slide

  65. JSON is difficult to evolve without breaking clients

    View Slide

  66. XML’s document model is built for extensibility

    View Slide



  67.    
           Bacon
           5.99
       

    View Slide



  68.    
           Bacon
           5.99
           OMNOMNOM  Bacon
       

    View Slide



  69.    
           Bacon
           5.99
       

    View Slide



  70.    
           Bacon
           5.99
           4.49
       

    View Slide



  71.    
           Bacon
           Speck
           5.99
           4.49
       

    View Slide



  72.    
           Bacon
           Speck
           5.99
           
       

    View Slide

  73. good hypermedia format example: the Lovefilm API

    View Slide



  74.    6
       1
       1
                       rel="self"  title="self"/>
                       rel="next"  title="next"/>
                       rel="last"  title="last"/>
       
           true
           2003-­‐09-­‐12
           
           http://openapi.lovefilm.com/catalog/title/59643
           false
           574
           4
           
           
           
           
           
                               rel="http://schemas.lovefilm.com/synopsis"  title="synopsis"/>
                               rel="http://schemas.lovefilm.com/reviews"  title="reviews"/>
                               rel="alternate"  title="web  page"/>
       

    View Slide

  75. ROOM FOR IMPROVEMENT IN
    THE LOVEFILM API
    • Uses application/xml instead of a custom media type
    • Once that is fixed, all the link elements could also have a
    “type” attribute indicating the media type
    • Should use XML namespaces on the root element, with one
    namespace per type (e.g. “urn:com.lovefilm.api.item”,
    “urn:com.lovefilm.api.searchresult” and so on)
    • That way, clients can determine the resource type easily

    View Slide

  76. another great RESTful API: Huddle

    View Slide

  77.    xmlns="http://schema.huddle.net/2011/02/"
       title="TPS  report  May  2010"
       description="relentlessly  mundane  and  enervating.">
       
       
       
       
       
       
       
       
       
       
       
       
           
           
           
       
       
       
           
           
           
       
       
       19475
       
       98
       2007-­‐10-­‐10T09:02:17Z
       2011-­‐10-­‐10T09:02:17Z
       Complete
       9

    View Slide

  78. ROOM FOR IMPROVEMENT IN
    THE HUDDLE API
    • Uses custom rels like “thumb” or “avatar” not defined in the
    IANA registry (http://www.iana.org/assignments/link-relations)
    • Risk of collisions and ambiguity; should use something like
    “http://rels.huddle.net/thumb” instead.
    • Uses one global XML schema and namespace for all entities
    • Clients cannot detect entity type based on namespace
    • Difficult to evolve schema versions independently

    View Slide

  79. API VERSIONING
    Media Types To The Rescue!

    View Slide

  80. why not api.myservice.com/v1/foo/bar?
    and then api.myservice.com/v2/foo/bar?

    View Slide

  81. different URLs means different resources!

    View Slide

  82. also, keep bookmarks (by machines) in mind

    View Slide

  83. GET  /products/1234  HTTP/1.1
    Host:  acme.com
    Accept:  application/vnd.com.myservice+xml
    HTTP/1.1  200  OK
    Content-­‐Type:  application/vnd.com.myservice+xml;  charset=utf-­‐8
    Allow:  GET,  PUT,  DELETE

                     id="1234"  xl:type="simple"  xl:href="http://acme.com/products/1234">
       Red  Stapler
       3.14

    API VERSION 1

    View Slide

  84. (item sells out...)

    View Slide

  85. GET  /products/1234  HTTP/1.1
    Host:  acme.com
    Accept:  application/vnd.com.myservice+xml
    HTTP/1.1  404  Not  Found
    Content-­‐Type:  application/vnd.com.myservice+xml;  charset=utf-­‐8
    API VERSION 1

    View Slide

  86. API now offers a new protocol version
    with availability indicators (breaking change!)

    View Slide

  87. GET  /products/1234  HTTP/1.1
    Host:  acme.com
    Accept:  application/vnd.com.myservice.v2+xml
    HTTP/1.1  200  OK
    Content-­‐Type:  application/vnd.com.myservice.v2+xml;  charset=utf-­‐8
    Allow:  GET,  PUT,  DELETE

                     id="1234"  xl:type="simple"  xl:href="http://acme.com/products/1234">
       Red  Stapler
       3.14
       false

    API VERSION 2

    View Slide

  88. clients can’t upgrade protocol for known URLs!

    View Slide

  89. Also, imagine every install of phpBB or Drupal had an API

    View Slide

  90. If the version is in the URL, clients need to regex those

    View Slide

  91. http://sharksforum.org/community/api/v1/threads/102152

    View Slide

  92. http://forum.sharksforum.org/api/v1/threads/102152

    View Slide

  93. that would be fail

    View Slide

  94. or what if another forum software wants the same API?

    View Slide

  95. also would have to use “/v1/” in their URLs

    View Slide

  96. URI based versioning kills interoperability

    View Slide

  97. YOU MIGHT BE WONDERING
    Why Exactly Is This Awesome?

    View Slide

  98. THE MERITS OF REST
    • Easy to evolve: add new
    features or elements without
    breaking BC
    • Easy to learn: developers can
    "browse" service via link rels
    • Easy to scale: grows well
    with number of participants
    (interoperability!)
    • Easy to implement: build it
    on top of HTTP, and profit!
    • Authentication & TLS
    • Caching & Load Balancing
    • Conditional Requests
    • Content Negotiation

    View Slide

  99. but...

    View Slide

  100. hold on, you say

    View Slide

  101. a plain HTTP-loving service does the job, you say

    View Slide

  102. surely, there is a merit to REST beyond extensibility, you ask

    View Slide

  103. nope

    View Slide

  104. "REST is software design on the scale of decades: every
    detail is intended to promote software longevity and
    independent evolution. Many of the constraints are
    directly opposed to short-term efficiency. Unfortunately,
    people are fairly good at short-term design, and usually
    awful at long-term design."
    Roy Fielding

    View Slide

  105. "Most of REST's constraints are focused on preserving
    independent evolvability over time, which is only
    measurable on the scale of years. Most developers
    simply don't care what happens to their product years
    after it is deployed, or at least they expect to be around
    to rewrite it when such change occurs."
    Roy Fielding

    View Slide

  106. FURTHER READING
    • Ryan Tomayko
    How I Explained REST to my Wife
    http://tomayko.com/writings/rest-to-my-wife
    • Jim Webber, Savas Parastatidis & Ian Robinson
    How to GET a Cup of Coffee
    http://www.infoq.com/articles/webber-rest-workflow
    • Roy Thomas Fielding
    Architectural Styles and the Design of Network-based Software
    Architectures
    http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

    View Slide

  107. BOOKS ON REST
    • Jim Webber, Savas Parastatidis, Ian Robinson
    REST in Practice
    ISBN: 978-0596805821
    • Subbu Allamaraju
    RESTful Web Services Cookbook
    ISBN: 978-0596801687
    • Leonard Richardson, Sam Ruby
    RESTful Web Services
    ISBN: 978-0596529260

    View Slide

  108. Fin

    View Slide

  109. Questions?

    View Slide

  110. THANK YOU!
    This was
    Designing RESTful Web Services
    by @dzuelke.
    Questions? [email protected]

    View Slide