Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Representational State Transfer


Published on

This presentation aimed to explain what is REST and why it is commonly misunderstood. It focuses on describing REST from scientific point of view, based on Roy`s Fielding dissertation.

Published in: Software, Technology
  • Be the first to comment

Representational State Transfer

  1. 1. Representational State Transfer Alexei Skachykhin – Software Engineer iTechArt, 2014
  2. 2. The Internet Of Things  Explosion of WWW  Smart Electronics  Web APIs
  3. 3. Painting Style What painting style is it? Cubism? Surrealism?
  4. 4. REST Like painting style, REST is a network architectural style Representational State Transfer
  6. 6. Who coined the term? Roy Fielding  Author of HTTP spec  Co-founder of Apache HTTP Server  Senior Principal scientist at Adobe
  7. 7. Who else? Mike Amundsen Leonard Richardson
  8. 8. Architectural Style Architectural style is basically set of constraints, and following them leads to gaining certain architectural properties (benefits)
  9. 9. Architectural Style Feature-driven Architectural Style
  10. 10. Architectural Style Constraints-driven Architectural Style
  11. 11. Properties of REST Heterogeny Scalability Evolvability Visibility Reliability Efficiency
  12. 12. Constraints Client-Server Stateless Cacheable Layered System Code on Demand Uniform Interface  Optional constraint
  13. 13. REST Derivation RR CS LS VM U $ CSS LCS COD C$SS LC$SS LCODC$SS REST layered on-demand stateless simple visible reliable shared extensible reusable scalable multi. org.
  14. 14. Client-Server  Separation of concerns  Independent development  Security is scoped to connections Benefits
  15. 15. Client-Server Wouldn`t that mean that Client-Side databases violate REST? NOT AT ALL ACTUALLY
  16. 16. Client-Server How does WebRTC fit into REST? IT DOESN`T
  17. 17. Stateless Each request from client to server must contain all of the information necessary to understand the request
  18. 18. Stateless Application State Resource State
  19. 19. Stateless  Simplified Scalability (CAP theorem)  Improved Reliability (recover from failures)  Visibility Benefits
  20. 20. Stateless  Performance decrease (repetitive data)  Risk of inconsistent app behavior Disadvantages
  21. 21. Cacheable Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable
  22. 22. Cacheable  Improved efficiency  Improved scalability  Improved user perceived performance Benefits
  23. 23. Layered system Allows an architecture to be composed of hierarchical layers
  24. 24. Layered system  Bound complexity  Improved scalability (load balancing) Benefits
  25. 25. Layered system  Increased latency  User-perceived performance may degrade Disadvantages
  26. 26. Code on Demand (Optional) REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts
  27. 27. Code on Demand (Optional)  Improved extensibility  Simplified clients Benefits
  28. 28. Uniform Interface Generalized interface between components. All of the components communicate through this interface
  29. 29. Uniform Interface  Improved visibility  Overall simplicity  Implementation decoupled from services Benefits
  30. 30. Uniform Interface BUT! Performance suffers!
  31. 31. Uniform Interface Identification of resources Manipulation of resources through representations Self-descriptive messages Hypermedia as the engine of application state
  32. 32. Uniform Interface Resources Resource is any concept that might be target of an author`s hypertext reference
  34. 34. Uniform Interface Resources  𝑀 𝑟 𝑡 , resource to set map  Static semantics  Many-to-Many
  35. 35. Uniform Interface Resources Don`t use database schema as a basis for Web API for couple of reasons  API clients care about application semantics not database schema, which is different thing  Changes to the database schema become impossible
  36. 36. Uniform Interface Resource Identification Not a word about URL format! It doesn`t matter!
  37. 37. Uniform Interface Resource Identification Hardcoded URLs or URL templates is a form of coupling!
  38. 38. Uniform Interface Resource Identification URI Templates (RFC 6570){username}/{term:1}/{term}{?q*,lang} { username: "rodneyrehm", term: "hello world", q: { a: "mars", b: "jupiter“ }, lang: "en" } +
  39. 39. Uniform Interface Manipulation of resources through representations A representation is a sequence of bytes, plus representation metadata to describe those bytes. Representation captures the state of resource.
  40. 40. Uniform Interface Manipulation of resources through representations  Can be any sequence of bytes  Resource can have multiple representations  Content negotiation is needed
  41. 41. Uniform Interface Manipulation of resources through representations Do I violate REST if I pick HTML as representation format? NO YOU DON`T
  42. 42. Uniform Interface HATEOAS HATEOAS! Is it a Greek got?
  43. 43. Uniform Interface HATEOAS Hypermedia as the engine of application state!
  44. 44. Uniform Interface HATEOAS You already know about Application State, right? At least I told you 10 minutes ago :)
  45. 45. Uniform Interface HATEOAS Hypermedia connects resources to each other, and describes their capabilities in machine-readable ways
  46. 46. Uniform Interface HATEOAS What to do next?
  47. 47. Uniform Interface HATEOAS What to do next? { "appnews": { "appid": 440, "newsitems": [{ "gid": "3189986872441392984", "title": "Team Fortress 2 Update Released", "url": "", "is_external_url": false, "author": "Valve", "feedlabel": "Product Update", "date": 1402535460, "feedname": "steam_updates“ }] } }
  48. 48. Uniform Interface HATEOAS “Hypermedia connects resources to each other, and describes their capabilities in machine-readable ways” - Roy Fielding
  49. 49. Uniform Interface HATEOAS Most of the “RESTful” Web APIs are not RESTful, because of lack of hypermedia
  50. 50. Uniform Interface HATEOAS  Decoupling between client and server  Resilience to API changes  Enhanced usability (no hardcode and doc issues) Why hypermedia is important for Web APIs?
  51. 51. Uniform Interface Hypermedia Aware Media Types Siren – generic hypermedia format { "class": ["owner", "vip"], "properties": { "name": "Kevin“ }, "entities": [ { "rel": [""], "href": } ], "actions": [ { "name": "adopt", "method": "POST", "href": "", "fields": [{ "name": "dog-name", "type": "text" }] } ], "links": [ { "rel": ["self"], "href": "" } ] } LinkLink Relation
  52. 52. Uniform Interface Hypermedia Aware Media Types SIREN, HAL, COLLECTION+JSON, JSON-LD, HYDRA, OData, AtomPub, HTML  W3C Spec
  53. 53. Uniform Interface HATEOAS Not a word about URL format! It doesn`t matter!
  54. 54. Uniform Interface HATEOAS Hardcoded URLs or URL templates is a form of coupling!
  55. 55. REST Flavor “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” - Roy Fielding
  56. 56. HTTP only? REST is not bound to HTTP Other implementations are: CoAP, Waka
  57. 57. Richardson Maturity Model Not only verbs but all HTTP facilities
  58. 58. Richardson Maturity Model Don`t reinvent the wheel, stick with capabilities of application protocol of your choice (HTTP mostly) HTTP Verbs, Status Codes, Headers
  59. 59. REST Religion REST is not a religion! Treat it as a reference network architecture of the Web
  60. 60. Links Roy`s Fielding dissertation: API Academy: Hypertext Driven API:
  61. 61. Thank you! Forward your questions to