rest
DESCRIPTION
Presentation about the basic principles in RESTTRANSCRIPT
![Page 1: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/1.jpg)
![Page 2: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/2.jpg)
![Page 3: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/3.jpg)
![Page 4: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/4.jpg)
Back to basics
Plain HTTP GET, PUT, DELETE XML, JSON or XHTML data
![Page 5: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/5.jpg)
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
![Page 6: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/6.jpg)
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
![Page 7: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/7.jpg)
“Design depends largely on constraints.”
— Charles Eames
![Page 8: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/8.jpg)
Roy Fielding
Attribution: Paul Downey http://blog.whatfettle.com
![Page 9: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/9.jpg)
Principles of REST
• Give every “thing” an ID
• Use a standard set of methods
• Link things together
• Communicate statelessly
![Page 10: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/10.jpg)
Addressability
Resources must be addressable Everything that matters should have its own
URI
![Page 11: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/11.jpg)
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
![Page 12: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/12.jpg)
Imagine the web without links
![Page 13: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/13.jpg)
Without linking
ServerClient
GET http://bjarlestam.com/slides
[slide1, slide2, slide3, slide4]
GET http://bjarlestam.com/slides/getSlide?id=slide1
![Page 14: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/14.jpg)
With linking
ServerClient
GET http://bjarlestam.com/slides
[ http://bjarlestam.com/slides/slide1, http://bjarlestam.com/slides/slide2, http://bjarlestam.com/slides/slide3, http://bjarlestam.com/slides/slide4 ]
GET http://bjarlestam.com/slides/slide1
![Page 15: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/15.jpg)
Why is it better to link the resources?
![Page 16: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/16.jpg)
Link your resources
• No out of band info needed
• No separate discovery mechanism
![Page 17: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/17.jpg)
Statelessness
![Page 18: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/18.jpg)
Imagine Google being stateful
![Page 19: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/19.jpg)
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
Stateful
![Page 20: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/20.jpg)
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
Stateless
![Page 21: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/21.jpg)
What makes the stateless Google better than the stateful?
![Page 22: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/22.jpg)
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
![Page 23: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/23.jpg)
Caching
![Page 24: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/24.jpg)
Client
ProxyCache
Client
Client
Server
ProxyCache
Client
ReverseProxyCache
ClientCache
ClientCache
ClientCache
ClientCache
![Page 25: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/25.jpg)
“The best requests are those that not even reach me.”
- Anonymous overloaded Server
![Page 26: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/26.jpg)
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
![Page 27: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/27.jpg)
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
![Page 28: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/28.jpg)
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.
![Page 29: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/29.jpg)
“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
![Page 30: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/30.jpg)
True!
Unless someone else has already done the thinking for you
![Page 31: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/31.jpg)
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 :-)
![Page 32: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/32.jpg)
JAX-RS Hello World
@Path("/helloworld")
public class HelloWorld {
@GET
@Produces("text/plain")
public String sayHello() {
return new String("Hello World!");
}
}
![Page 33: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/33.jpg)
@Path("/slides")
public class SlideResource {
Map<Slide> slides;
@GET
@Path("{id}")
@Produces("text/html")
public String getSlideAsHtml(@PathParam("id") String slideId) {
return slides.get(slideId).getAsHtml();
}
...
}
JAX-RS
![Page 34: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/34.jpg)
@Path("/slides")
public class SlideResource {
Map<Slide> slides;
...
@PUT
@Path("{id}")
@Consumes("application/json")
public String save(@PathParam("id") String slideId, String content) {
slides.put(slideId, new Slide(content));
return "slide with id " + slideId + " stored";
}
}
JAX-RS
![Page 35: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/35.jpg)
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
![Page 36: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/36.jpg)
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
![Page 37: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/37.jpg)
For the interested
![Page 38: REST](https://reader033.vdocuments.net/reader033/viewer/2022052822/554f579bb4c905423f8b56b4/html5/thumbnails/38.jpg)
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/