Your SlideShare is downloading. ×
Representational State Transfer
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Representational State Transfer

307
views

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.

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
307
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Representational State Transfer Alexei Skachykhin – Software Engineer iTechArt, 2014
  • 2. The Internet Of Things  Explosion of WWW  Smart Electronics  Web APIs
  • 3. Painting Style What painting style is it? Cubism? Surrealism?
  • 4. REST Like painting style, REST is a network architectural style Representational State Transfer
  • 5. REST NO SPEC! NO PROTOCOL!
  • 6. Who coined the term? Roy Fielding  Author of HTTP spec  Co-founder of Apache HTTP Server  Senior Principal scientist at Adobe
  • 7. Who else? Mike Amundsen Leonard Richardson
  • 8. Architectural Style Architectural style is basically set of constraints, and following them leads to gaining certain architectural properties (benefits)
  • 9. Architectural Style Feature-driven Architectural Style
  • 10. Architectural Style Constraints-driven Architectural Style
  • 11. Properties of REST Heterogeny Scalability Evolvability Visibility Reliability Efficiency
  • 12. Constraints Client-Server Stateless Cacheable Layered System Code on Demand Uniform Interface  Optional constraint
  • 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. Client-Server  Separation of concerns  Independent development  Security is scoped to connections Benefits
  • 15. Client-Server Wouldn`t that mean that Client-Side databases violate REST? NOT AT ALL ACTUALLY
  • 16. Client-Server How does WebRTC fit into REST? IT DOESN`T
  • 17. Stateless Each request from client to server must contain all of the information necessary to understand the request
  • 18. Stateless Application State Resource State
  • 19. Stateless  Simplified Scalability (CAP theorem)  Improved Reliability (recover from failures)  Visibility Benefits
  • 20. Stateless  Performance decrease (repetitive data)  Risk of inconsistent app behavior Disadvantages
  • 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. Cacheable  Improved efficiency  Improved scalability  Improved user perceived performance Benefits
  • 23. Layered system Allows an architecture to be composed of hierarchical layers
  • 24. Layered system  Bound complexity  Improved scalability (load balancing) Benefits
  • 25. Layered system  Increased latency  User-perceived performance may degrade Disadvantages
  • 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. Code on Demand (Optional)  Improved extensibility  Simplified clients Benefits
  • 28. Uniform Interface Generalized interface between components. All of the components communicate through this interface
  • 29. Uniform Interface  Improved visibility  Overall simplicity  Implementation decoupled from services Benefits
  • 30. Uniform Interface BUT! Performance suffers!
  • 31. Uniform Interface Identification of resources Manipulation of resources through representations Self-descriptive messages Hypermedia as the engine of application state
  • 32. Uniform Interface Resources Resource is any concept that might be target of an author`s hypertext reference
  • 33. Uniform Interface Resources DOCUMENT, IMAGE, PERSON, COLLECTION OF FAVOURITE MOVIES, E.T.C.
  • 34. Uniform Interface Resources  𝑀 𝑟 𝑡 , resource to set map  Static semantics  Many-to-Many
  • 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. Uniform Interface Resource Identification Not a word about URL format! It doesn`t matter!
  • 37. Uniform Interface Resource Identification Hardcoded URLs or URL templates is a form of coupling!
  • 38. Uniform Interface Resource Identification URI Templates (RFC 6570) http://example.org/~{username}/{term:1}/{term}{?q*,lang} { username: "rodneyrehm", term: "hello world", q: { a: "mars", b: "jupiter“ }, lang: "en" } + http://example.org/~rodneyrehm/h/hello%20world?a=mars&b=jupiter&lang=en
  • 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. Uniform Interface Manipulation of resources through representations  Can be any sequence of bytes  Resource can have multiple representations  Content negotiation is needed
  • 41. Uniform Interface Manipulation of resources through representations Do I violate REST if I pick HTML as representation format? NO YOU DON`T
  • 42. Uniform Interface HATEOAS HATEOAS! Is it a Greek got?
  • 43. Uniform Interface HATEOAS Hypermedia as the engine of application state!
  • 44. Uniform Interface HATEOAS You already know about Application State, right? At least I told you 10 minutes ago :)
  • 45. Uniform Interface HATEOAS Hypermedia connects resources to each other, and describes their capabilities in machine-readable ways
  • 46. Uniform Interface HATEOAS What to do next?
  • 47. Uniform Interface HATEOAS What to do next? { "appnews": { "appid": 440, "newsitems": [{ "gid": "3189986872441392984", "title": "Team Fortress 2 Update Released", "url": "http://store.steampowered.com/news/13634/", "is_external_url": false, "author": "Valve", "feedlabel": "Product Update", "date": 1402535460, "feedname": "steam_updates“ }] } }
  • 48. Uniform Interface HATEOAS “Hypermedia connects resources to each other, and describes their capabilities in machine-readable ways” - Roy Fielding
  • 49. Uniform Interface HATEOAS Most of the “RESTful” Web APIs are not RESTful, because of lack of hypermedia
  • 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. Uniform Interface Hypermedia Aware Media Types Siren – generic hypermedia format { "class": ["owner", "vip"], "properties": { "name": "Kevin“ }, "entities": [ { "rel": ["https://rels.x.io/dog"], "href": https://api.x.io/dogs/1 } ], "actions": [ { "name": "adopt", "method": "POST", "href": "https://api.x.io/owners/1/dogs", "fields": [{ "name": "dog-name", "type": "text" }] } ], "links": [ { "rel": ["self"], "href": "https://api.x.io/owners/1" } ] } LinkLink Relation
  • 52. Uniform Interface Hypermedia Aware Media Types SIREN, HAL, COLLECTION+JSON, JSON-LD, HYDRA, OData, AtomPub, HTML  W3C Spec
  • 53. Uniform Interface HATEOAS Not a word about URL format! It doesn`t matter!
  • 54. Uniform Interface HATEOAS Hardcoded URLs or URL templates is a form of coupling!
  • 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. HTTP only? REST is not bound to HTTP Other implementations are: CoAP, Waka
  • 57. Richardson Maturity Model Not only verbs but all HTTP facilities
  • 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. REST Religion REST is not a religion! Treat it as a reference network architecture of the Web
  • 60. Links Roy`s Fielding dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm API Academy: http://www.apiacademy.co/ Parse.com https://parse.com/ Hypertext Driven API: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  • 61. Thank you! Forward your questions to alexei.skachykhin@live.com