REST: Theory vs Practice
Download as ZIP, PDF1 like4,828 views
This document discusses REST theory versus practice. It begins with introducing the two speakers, Subbu Allamaraju and Mike Amundsen. The objectives of the talk are then outlined, which are to understand that REST is a set of constraints that can be knowingly relaxed, work with underlying protocols, and apply sound software engineering. Common REST principles are then explained including identifying resources, using URIs, designing representations, using a uniform interface, and using hypermedia as the engine of application state. An example address book REST API is then demonstrated. The talk concludes by discussing practical considerations when implementing REST including managing concurrency, being creative with URIs, and that IDs alone are not as good as full URIs.
![Address
Book
1.1
[UC]
Support
address
book
sync
for
mobile
users
10/06/2009
12](https://image.slidesharecdn.com/jaoo09-091007040034-phpapp01/85/REST-Theory-vs-Practice-12-320.jpg)
REST: Theory vs Practice
- 1. REST – Theory vs Practice Subbu Allamaraju Mike Amundsen 10/06/2009 1
- 2. About the Speakers Subbu Allamaraju Architect, Yahoo! Web services standards/practices at Yahoo! Built web portals, and web/WS services (SOAP kind) frameworks (BEA Systems) Mike Amundsen Independent Consultant .NET Long‐time RESTafarian 10/06/2009 2
- 3. RESTful Web Services Cookbook O’Reilly, March 2010 10/06/2009 3
- 4. Objectives REST is set of constraints and not rules Knowingly relax constraints Work with the plumbing Apply sound software engineering 10/06/2009 4
- 5. REST as Explained 1. Identify resources 2. Give a URI to every resource 3. Design representations for resources 4. Operate using a uniform interface 5. Use hypermedia as the engine of application state 10/06/2009 5
- 6. Address Book 1.0 Build a RESTful address book 10/06/2009 6
- 7. GET /user/subbu/address/{id} Host: ex.org 200 OK ... PUT /user/subbu/address/{id} Host: ex.org Address If-Match: xyz Resource 200 OK ... DELETE /user/subbu/address/{id} Host: ex.org If-Match: xyz 200 OK ... POST /user/subbu/address-book Address Host: ex.org Collection 201 Created ... Resource 10/06/2009 7
- 8. <address> <link rel=“http://ex.org/rel/person” href=“http://ex.org/mike”/> <street>...</street> <city>...</city> ... </address> <address-book> <link rel=“http://ex.org/rel/owner” href=“http://ex.org/subbu”/> <link rel=“next” href=“http://ex.org/subbu/address-book?p=2/”/> <address>...</address> <address>...</address> ... </address-book> 10/06/2009 8
- 9. ✔ URIs GET /user/subbu/address/{id} Host: ex.org ✔ Resources 200 OK ... PUT /user/subbu/address/{id} Host: ex.org Address If-Match: xyz Resource 200 OK ... DELETE /user/subbu/address/{id} Host: ex.org Uniform interface ✔ If-Match: xyz 200 OK ... POST /user/subbu/address-book Address Host: ex.org Collection 201 Created ... Resource 10/06/2009 9
- 10. <address> 4 Representations <link rel=“http://ex.org/rel/person” href=“http://ex.org/subbu”/> <street>...</street> <city>...</city> ... </address> <address-book> <link rel=“self” href=“http://ex.org/subbu/address-book”/> 5 Application state <link rel=“next” href=“http://ex.org/subbu/address-book?p=2/”/> <address>...</address> <address>...</address> ... </address-book> 10/06/2009 10
- 11. Stateless Uniform Self‐ Interactions Interface Describing Visibility HTTP goodies – caching, optimistic concurrency, conneg, monitoring, analytics + others 10/06/2009 11
- 12. Address Book 1.1 [UC] Support address book sync for mobile users 10/06/2009 12
- 13. Address GET /user/subbu/address-book Collection Resource For each address in the collection Compare local copy PUT if different Address DELETE if missing Resource Address POST if new Collection Resource 10/06/2009 13
- 14. Separation of concerns Visibility Network efficiency 10/06/2009 14
- 15. Better Merge POST /user/subbu/address-book/merge Host: ex.org Content-Length: xxx Content-Type: application/xml;charset=UTF-8 <address-book> <address>...</address> <address>...</address> ... </address-book> 303 See Other Location: http://ex.org/user/subbu/address-book 10/06/2009 15
- 16. POST /user/subbu/address-book/merge Host: ex.org Content-Type: application/xml;charset=UTF-8 ? Reduced visibility <address-book> <address>...</address> <address>...</address> ✔ Better separation of concerns ... </address-book> ✔ Efficient network use 303 See Other Location: http://ex.org/user/subbu/address-book 10/06/2009 16
- 17. Protocol‐level Visibility Separation of Concerns Tradeoffs Network Efficiency Atomicity and Concurrency Infrastructure support 10/06/2009 17
- 18. Take a Step Back 10/06/2009 18
- 19. 1. Everything at the end of a URI is a resource Some “things” “person”, “address book” and some non‐“things” “merge address book”, “reserve”, “cancel”, “compute distance”, “reimage the virtual machine” 10/06/2009 19
- 20. 2. Use POST when in doubt GET Safe + Idempotent PUT Unsafe + Idempotent DELETE Unsafe + Idempotent POST Unsafe + Non‐Idempotent All bets are off with POST POST limits damage 10/06/2009 20
- 21. 3. Don’t tunnel using POST POST /address-book Merge an address book? Fix duplicates? Or something else? Tunneling = Back to dark ages 10/06/2009 21
- 22. This is not a “pedantic” point of view Browser Proxy Web (JS Client) Server Server Dev: “We should find a way to make REST 'faster' and/or provide batching support” 10/06/2009 22
- 23. A benign solution? Batch “end point” Browser Proxy (JS Client) Server Web Server POST /batch Host: ex.org Content-Length: xxx Content-Type: application/xml;charset=UTF-8 <batch> <request method=“PUT” uri=“/addr”>...</request> <request method=“GET” uri=“/poi”>...</request> <request method=“GET” uri=“/deals”>...</request> </batch> 10/06/2009 23
- 24. Browser Proxy Web (JS Client) Server Server Bad Guy Batch “end point” Browser Proxy (JS Client) Server Web Server 10/06/2009 24
- 25. ✗ POST /batch Host: ex.org Content-Length: xxx Content-Type: application/xml;charset=UTF-8 <batch>...</batch> Create application specific resources with distinct URIs POST /updateAddressGetPoiDeals Host: ex.org ✓ Content-Length: xxx Content-Type: application/xml;charset=UTF-8 <address> ... </address> 10/06/2009 25
- 26. 4. Be creative with URIs Fixed and known URIs (Cool URIs) http://ex.org/user/subbu Resources with many URIs http://ex.org/user/1234/profile;t=3231231dasd http://ex.org/user/1234/profile;t=3da8432stgs Ephemeral URIs (Uncool URIs) http://ex.org/act/4567/status;t=rfdsf3adsd23das http://ex.org/act/transfer? f=12&t=32&sig=a359d72d424cbd913686435bc6e7e372 10/06/2009 26
- 27. 5. IDs are not bad, but URIs are better How much “hyper”media? Should you care? Separation of concerns Performance Loose coupling App complexity 10/06/2009 27
- 28. <album> <photo id=“1234”>...</photo> <photo id=“5678”>…</photo> Bad? </album> <album xml:base=“http://ex.org”> <photo> <link href=“/photo/1234”/>... </photo> Good? <photo> <link href=“/photo/5678”/>... </photo> </album> 10/06/2009 28
- 29. Schedule interview Candidate Enter feedback Candidate Enter reference checks Hire Candidate No hire 10/06/2009 29
- 30. GET /transfer/token?from=1234&to=5678 Host: ex.org 200 OK Content-Type: application/xml;charset=UTF-8 <token> <link rel=“http://ex.org/rels/transfer” href=“http://ex.org/transfer;9ihrdsadas”/> <from> <balance>...</balance> </from> <to> <balance>...</balance> </to> </token> 10/06/2009 30
- 31. URI decoupling ***** Application flow ***** Opaque application state ***** 10/06/2009 31
- 32. 6. Managing concurrency GET /subbu/address/1 200 OK Date: Mon, 28 Sep 2009 14:30:53 GMT Etag: “8cf498a1ca3ceb67fe50d401d4759e34” Last-Modified: Mon, 28 Sep 2009 01:30:53 GMT Cache-Control: public,max-age=3600 <address>...</address> PUT /subbu/address/1 If-Unmodified-Since: Mon, 28 Sep 2009 14:30:53 GMT If-Match: “8cf498a1ca3ceb67fe50d401d4759e34” 412 Precondition Failed 10/06/2009 32
- 33. GET /acct/1234 200 OK ETag: "f091aae21b44c71:6b9" Content-Type: application/xml;charset=UTF-8 <account> ... </address> GET /acct/5678 ... POST /transfer Host: ex.org Content-Type: application/x-www-form-urlencoded amount=1000&from=1234&to=5678... 10/06/2009 33
- 34. GET /acct/1234 200 OK ETag: "f091aae21b44c71:6b9" Content-Type: application/xml;charset=UTF-8 <account> ... </address> GET /acct/5678 ✗ No concurrency control ... POST /transfer Host: ex.org Content-Type: application/x-www-form-urlencoded amount=1000&from=1234&to=5678... 10/06/2009 34
- 35. GET /transfer/token?from=1234&to=5678 Host: ex.org 200 OK Content-Type: application/xml;charset=UTF-8 <token> <link rel=“http://ex.org/rels/transfer” href=“http://ex.org/transfer;9ihrdsadas”/> <from> <balance>...</balance> </from> <to> <balance>...</balance> </to> </token> 10/06/2009 35
- 36. POST /transfer/token;9ihrdsadas Host: ex.org Content-Type: application/x-www-form-urlencoded amount=1000 201 Created Location: http://ex.org/transfer/1234 Content-Type: application/xml;charset=UTF-8 <transfer> <created>2009‐09‐30T15:00:00Z</created> <from> <balance>...</balance> </from> <to> ✔ Concurrency control <balance>...</balance> </to> </transfer> 10/06/2009 36
- 37. 7. Caching is not perfect HTTP Client Cache Data Server Ideal – perfectly visible 10/06/2009 37
- 38. Client Data HTTP Data Client Cache Server Data Client Cache Cache Other apps 10/06/2009 38
- 39. Every row is a resource 10/06/2009 39
- 40. Overlapping data 10/06/2009 40
- 41. Some resources are like home pages 10/06/2009 41
- 42. No conditional reads No writes on Accept staleness overlapping resources 10/06/2009 42
- 43. Conclusion Focus on tradeoffs Relax constraints judiciously, but not accidentally or by ignorance Put HTTP and its plumbing to good use 10/06/2009 43