RESTful Web Services

23,421 views

Published on

Recently gave this presentation. Nick Spilman did a Grails demo to demonstrate REST web services.

Published in: Technology
2 Comments
57 Likes
Statistics
Notes
No Downloads
Views
Total views
23,421
On SlideShare
0
From Embeds
0
Number of Embeds
185
Actions
Shares
0
Downloads
0
Comments
2
Likes
57
Embeds 0
No embeds

No notes for slide

RESTful Web Services

  1. 1. Christopher Bartling Nick Spilman Kevin Hakanson
  2. 2. Basic REST concepts  Defining your Resource-oriented architecture  HTTP status codes and error handling  Content-type negotiation  Using AJAX with REST  Versioning REST APIs  Caching and other performance  considerations
  3. 3. REpresentational State Transfer  Architecture style or design criteria   Not a standard Stateless, client-server, cacheable  communications protocol Use HTTP requests to post, read, and delete  data. Lightweight  Nouns as URI, verbs as HTTP method 
  4. 4. Resource   Anything that important enough to be referenced in its singularity  Can be physical object or an abstract concept  Every resource has at least one name Resources can be a container of other  resources  Containers are always resources  Composite design pattern
  5. 5. Resource representation   Any useful information about the state of a resource  Specified through distinct URI or content negotiation through headers Canonical resource URI   Independent of format or locale language  Can be specified in Content-Location response header of representation response
  6. 6. GET  http://www.example.com/v1/hr/employees/19328389 POST  http://www.example.com/v1/hr/employees DELETE  http://www.example.com/v1/hr/employees/14283949 PUT  http://www.example.com/v1/hr/employees/13448784
  7. 7. Addressability   Resources are identified by URIs Statelessness   No connection state maintained between REST invocations Connectedness   Resources should link together in their representations Uniform interface   HTTP GET, PUT, POST, DELETE, HEAD, OPTIONS  HTTP method header  HTTP status codes
  8. 8. The name and address of a resource   The scoping information to resources  Principle of addressability Should be descriptive  Unique URIs are exposed for every resource  available from a RESTful system  Every URI designates exactly one resource URIs are discoverable by your clients 
  9. 9. No state stored on the server  Every HTTP request executes in complete  isolation on the server Simpler to design and evolve  Easier to scale  Avoid using HTTP sessions and cookies  No side-effects 
  10. 10. Standardized   GET  POST  PUT  DELETE  HEAD  OPTIONS Represents invocation action  Resources expose uniform interface 
  11. 11. Primary means of reporting the outcome of a  REST operation  Use the entity-body to add ancillary qualifiers to the outcome  Do not send back resource representations for anything other than GET—negative impact on performance optimizations See Appendix B of RESTful Web Services  book for top 42 HTTP status codes
  12. 12. GET and HEAD requests should not cause any  disastrous changes to the server-side No side effects!   Client should not be making requests just for the side effects Avoid exposing unsafe operations through  GET
  13. 13. Multiple invocations of an operation results in  the same result state as a single invocation Idempotent methods: GET, HEAD, PUT,  DELETE , OPTIONS Not idempotent: POST 
  14. 14. When creating and updating resources…   PUT if, and only if, you can fully specify the full content of the resource  POST if you are sending a command to create or update one or more subordinates of the specified resource  With POST, the server will determine resource URI Use Location header in the POST response to  specify new resource URI(s) if applicable
  15. 15. HTTPS and SSL certificate validation  5 main HTTP methods   GET, HEAD, POST, PUT, DELETE Customization of the data sent in the entity-  body of a PUT or POST request Customization of HTTP headers  Access to the response status code and  headers Communicate through HTTP proxies 
  16. 16. Transfer and handle compressed data   Request: Accept-Encoding header  Response: Encoding header Cache responses to requests   Conditional GETs Common forms of HTTP authentication   Basic, Digest, and WSSE Transparently follow HTTP redirects 
  17. 17. Hierarchical   Encode data into path variables on the URI  http://maps.example.com/Earth/Europe/France/Paris No hierarchy   Combine into one path variable, separated by commas or semicolons  Use commas when order is important, semicolons when it doesn’t  http://maps.example.com/Earth/24.9195,17.821
  18. 18. Algorithmic resources   Use query variables  http://www.google.com/search?q=rest
  19. 19. Version your services!  Incorporate the version into the URI   Set version to the first path variable  GET /v1/users/34923408 Representations should also be versioned   Include version information in the representation
  20. 20. Most resources do not change much  Saves client and server processing time and  network bandwidth Implemented using HTTP headers   Response headers: Last-Modified and ETag  Request headers: If-Modified-Since and If-None- Match
  21. 21. Initial request for resource representation
  22. 22. Request  GET /v1/users/10572 HTTP/1.1 Response  HTTP/1.1 200 OK Last-Modified: Mon, 13 Apr 2009 18:00:00 GMT ETag: 1239646841000 Cache-Control: must-revalidate Expires: Thu, 01 Jan 1970 00:00:00 GMT Date: Mon, 13 Apr 2009 18:46:00 GMT
  23. 23. Subsequent requests for resource representation
  24. 24. Request  GET /v1/users/10572 HTTP/1.1 If-Modified-Since: Mon, 13 Apr 2009 18:00:00 GMT If-None-Match: 1239646841000 Response  HTTP/1.1 304 Not Modified Date: Mon, 13 Apr 2009 18:47:00 GMT
  25. 25. Microsoft Internet Explorer   Requires the Expires: -1 header  Prevents caching in IE http://support.microsoft.com/kb/234067
  26. 26. Tools   .NET ▪ Windows Communication Foundation (WCF)  Java ▪ Spring MVC 3.0 ▪ JAX-RS: CXF, Jersey, RESTEasy, RESTlet Design the REST API   Don’t just let it happen!  Seek out resources in your domain
  27. 27. Answer the following questions, in order:  1. What are the URIs? What are the resources of your application? 2. What is the representational format for the resources? 3. What methods are supported at each URI? 4. What status codes could be returned for each method?
  28. 28. Resources can be served in different  representations  XML, JSON, HTML, etc. Content negotiation methods   Headers ▪ Accept or Content-Type  Query parameter ▪ GET /v1/users/10572?format=json  URI extension ▪ GET /v1/users/10572.xml
  29. 29. Tools   Curl  Apache HttpClient and JUnit  Fiddler (Windows), HTTP Scoop (OS X), WireShark
  30. 30. Using REST as a RPC-like mechanism  Overusing POST  Putting actions in the URI  Disguising a service as a resource  Maintaining sessions on the server 
  31. 31. RESTful Web Services. Leonard Richardson and Sam Ruby.  http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/  http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-  vs-put/ http://www.xml.com/pub/a/2004/12/01/restful-web.html  http://www.xml.com/pub/a/2004/03/17/udell.html  http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm  http://www.mozilla.org/projects/netlib/http/http-caching-faq.html  http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html 

×