REST, l'Architecture Incomprise (PHPTour)

REST, l'Architecture Incomprise (PHPTour)

REST est une architecture pour développer des APIs qui repose sur le protocole HTTP combiné à de nombreuses contraintes. Retour sur plus de trois années d'évangélisation avec un bilan mitigé : personne (ou presque) ne comprend vraiment REST, mais ce n'est pas si grave parce qu'il faut savoir être pragmatique et c'est ce que nous verrons !

Online slides: http://slides.williamdurand.fr/nobody-understands-rest/
Sources: https://github.com/willdurand-slides/nobody-understands-rest

F59d2f1ed66b8d9c6ceebea5a748494b?s=128

William Durand

May 12, 2015
Tweet

Transcript

  1. Nobody Understands REST but it is ok ;-) William Durand

    - May 12th, 2015
  2. A Few Words on REST

  3. REpresentational State Transfer REST is the underlying architectural principle of

    the web. It is formalized as a set of constraints, described in Roy Fielding's PhD dissertation.
  4. Richardson Maturity Model http://martinfowler.com/articles/richardsonMaturityModel.html

  5. Levels 0, 1, and 2 It is all about resources

    Client uses specific HTTP verbs Server uses HTTP status codes Content Negotiation
  6. Level 3 - Hypermedia Controls Service discovery via relations Hypermedia

    formats (e.g. HTML, HAL, JSON-LD) Resources are not important, their representations are! URI design does not matter (URI template) Client's experience is crucial! Protocol & application semantics
  7. HATEOAS Hypermedia As The Engine Of Application State It means

    that hypermedia should be used to find your way through the API. It is all about state transitions. Your application is just a big state machine.
  8. Application State [null] Homepage GET / User list GET /users

    POST /users User #123 GET /users/123
  9. Resource State Initial state New state Homepage GET / User

    list (2 users) GET /users User list (3 users) POST Homepage GET / GET /users
  10. Resource vs Representation A resource can be anything, and can

    have more than one representation. A representation describes resource state.
  11. Protocol Semantics How the underlying resource should behave under HTTP?

  12. Application Semantics What specifically will happen to application or resource

    state?
  13. The Semantic Challenge* Some standards have a good protocol-level semantics

    but no application-level semantics ( Collection+JSON , Atom ). Some standards define a lot of application-level semantics but no protocol semantics ( Microformats , Microdata ). * as described in Richardson and Amundsen's "RESTful Web APIs" book
  14. Profiles A profile is defined to not alter the semantics

    of the resource representation itself, but to allow clients to learn about additional semantics, . It does not have to be machine-readable but it is recommended. RFC 6906
  15. Examples Traditional API documentation XMDP (for XHTML documents) ALPS (

    XMDP on steroids) Embedded doc. (as in HAL / Siren ) JSON-LD
  16. How To Design A Web API?

  17. 1. List The Semantic Descriptors

  18. 2. Draw A State Diagram Each "box" represents one kind

    of representation Arrows are the state transitions (HTTP requests) Change descriptors to relations when it makes sense
  19. 3. Use Strings From Existing Profiles

  20. 4. Choose A Media Type Don't define your own, please.

  21. 5. Write A Profile That Documents Your Application Semantics

  22. 6. Eat. Sleep. Code. Repeat.

  23. 7. Publish The "First" URL

  24. Mmmmh

  25. State Of The Art Industry

  26. We all want RESTful APIs

  27. Yes.

  28. Is My API RESTful When I Use JSON? , The

    REST CookBook. Short answer: no. Long answer: no, not yet. RESTful API must use hypermedia formats. JSON is not a hypermedia format
  29. s/REST/HTTP++/ REST APIs are a myth, i.e. too complex in

    real life. , Steve Klabnik . 99.99% of the RESTful APIs out there aren’t fully compliant with Roy Fielding’s conception of REST
  30. No Relations = No REST , Roy Fielding. If the

    engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API
  31. Does It Matter?

  32. Beyond The Constraints

  33. Often Too Much How many clients do you have? Do

    you know any RESTful client? Writing smart clients is complicated
  34. Real Life #1 , Facebook (on Relay/GraphQL). Because of multiple

    round-trips and over-fetching, applications built in the REST style end up building ad hoc endpoints
  35. Real Life #2 , Netflix. Pure REST: Slow, hard to

    program, and rare
  36. Introducing HTTP++ APIs Well-designed, pragmatic, and future-proof APIs.

  37. Design your API from a client perspective

  38. Think in terms of representations

  39. Stick to HTTP

  40. Still really want to build a RESTful API? Choose the

    JSON-LD format.
  41. So What?

  42. It is ok not to build RESTful APIs

  43. "REST" is a (marketing) buzzword

  44. REST is not a silver bullet

  45. Thank You. Questions? è joind.in/14276 ¾ williamdurand.fr ® github.com/willdurand ¬

    twitter.com/couac
  46. Links Hypertext Application Language JSON-LD Collection+JSON Microformats XHTML Meta Data

    Profiles Application Language Profile Specification Microdata Siren http://restfulwebapis.com/