Your SlideShare is downloading. ×

REST

1,508

Published on

Presentation about the basic principles in REST

Presentation about the basic principles in REST

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,508
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
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. Back to basics  Plain HTTP  GET, PUT, DELETE  XML, JSON or XHTML data
  • 2. Time for some examples • iTunes top 10 songs – http://ax.itunes.apple.com/WebObjects/MZStoreServices.woa/ws/RSS/topsongs/limit=10/xml • Twitter – http://twitter.com/statuses/user_timeline/7355792.atom – http://twitter.com/statuses/user_timeline/7355792.json – http://twitter.com/friends/ids.json?user_id=7355792 • Google Maps – http://maps.google.com/staticmap?center=40.714728,-73.998672&zoom=12&size=400x400
  • 3. How RESTful is it?  Are all plain HTTP APIs REST?  Most services that claim to be REST are actually not  There are some rules to follow
  • 4. “Design depends largely on constraints.” — Charles Eames
  • 5. Roy Fielding file:///Users/andreas/Documents/workspace/RestfulSlideshowApplication/war/images/roy_fielding.jpg
  • 6. Principles of REST • Give every “thing” an ID • Use a standard set of methods • Link things together • Communicate statelessly
  • 7. Addressability  Resources must be addressable  Everything that matters should have its own URI
  • 8. Uniform Interface  Well defined set of operations  GET, PUT, DELETE, POST  Well defined semantics  GET does not kill kittens  PUT and DELETE are idempotent  POST is unsafe  A client knows exactly what it can do with a resource
  • 9. Imagine the web without links
  • 10. Without linking GET http://bjarlestam.com/slides [slide1, slide2, slide3, slide4] Client Server GET http://bjarlestam.com/slides/getSlide?id=slide1
  • 11. With linking GET http://bjarlestam.com/slides [ http://bjarlestam.com/slides/slide1, http://bjarlestam.com/slides/slide2, http://bjarlestam.com/slides/slide3, Client http://bjarlestam.com/slides/slide4 ] Server GET http://bjarlestam.com/slides/slide1
  • 12. Why is it better to link the resources?
  • 13. Link your resources • No out of band info needed • No separate discovery mechanism
  • 14. Statelessness
  • 15. Imagine Google being stateful
  • 16. Stateful http://www.google.com/search?q=rest&page=first http://www.google.com/search?q=rest&page=next http://www.google.com/search?q=rest&page=next
  • 17. Stateless http://www.google.com/search?q=rest http://www.google.com/search?q=rest&start=10 http://www.google.com/search?q=rest&start=20
  • 18. What makes the stateless Google better than the stateful?
  • 19. Statelessness • Better scaling – No session storage on server – Any server in a cluster can handle any request – All the result pages can safely be cached • More reliable – A client can safely re-send a request • Better resource reuse – All the result pages can safely be linked to
  • 20. Caching
  • 21. Client Cache Client Client Cache Client Proxy Cache Client Cache Server Client Reverse Proxy Cache Client Proxy Cache Cache Client
  • 22. “The best requests are those that not even reach me.” - Anonymous overloaded Server
  • 23. Caching  GET can be cached while POST can't (safely)  Specify max-age – Use max-age cache control header  Split data according to freshness requirement  Separate private and public data – Use private and public cache control header  Support conditional GET – Get if modified since – E-tags
  • 24. Media Types • A resource can have different representations – Ex: an image can be available as gif or jpeg • Media types can be negotiated with HTTP – Client can send Accept headers • Prefer media types that lets you link resources – Atom – XHTML+Microformats
  • 25. Some benefits of REST  Faster response time (caching)  Reduced server load (caching)  Improved server scalability (no session state)  Client software can be reused (uniform interface)  No separate resource discovery needed (hyperlinks)  Easy to serve different types of content such as images, videos, xl-sheets etc.
  • 26. “I think most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result.” - Roy Fielding
  • 27. True! Unless someone else has already done the thinking for you
  • 28. JAX-RS • Simple URL mappings • Simple media type specification • Simple Cache-control header handling • Simple HTTP response code handling • Support when building URLs • The REST is up to you :-)
  • 29. JAX-RS Hello World @Path(quot;/helloworldquot;) public class HelloWorld { @GET @Produces(quot;text/plainquot;) public String sayHello() { return new String(quot;Hello World!quot;); } }
  • 30. JAX-RS @Path(quot;/slidesquot;) public class SlideResource { Map<Slide> slides; @GET @Path(quot;{id}quot;) @Produces(quot;text/htmlquot;) public String getSlideAsHtml(@PathParam(quot;idquot;) String slideId) { return slides.get(slideId).getAsHtml(); } ... }
  • 31. JAX-RS @Path(quot;/slidesquot;) public class SlideResource { Map<Slide> slides; ... @PUT @Path(quot;{id}quot;) @Consumes(quot;application/jsonquot;) public String save(@PathParam(quot;idquot;) String slideId, String content) { slides.put(slideId, new Slide(content)); return quot;slide with id quot; + slideId + quot; storedquot;; } }
  • 32. Describing the interface  REST services should be self-descriptive  Client can use HTTP OPTIONS command  Content-type headers  Links let the client navigate the API  In theory no description language should be needed  There are some description languages though  WADL  WSDL2.0
  • 33. PUT or POST?  New resources could be created by either PUT or POST  Use PUT to create or edit a resource at a known URL  Use POST to create a resource and let the server decide the URL
  • 34. For the interested
  • 35. For the interested  Roy Fieldings PhD dissertation, see ch 5 – http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm  Roy Fieldings blog – http://roy.gbiv.com/untangled/  Mark Hadleys blog – http://weblogs.java.net/blog/mhadley/  Mark Nottinghams blog – http://www.mnot.net  Stefan Tilkovs blog – http://www.innoq.com/blog/st/

×