SJUG March 2010 Restful design
Upcoming SlideShare
Loading in...5
×
 

SJUG March 2010 Restful design

on

  • 1,314 views

Sydney Java Users Group - RESTful design explained

Sydney Java Users Group - RESTful design explained

Statistics

Views

Total Views
1,314
Views on SlideShare
1,221
Embed Views
93

Actions

Likes
0
Downloads
28
Comments
0

7 Embeds 93

http://michaelneale.blogspot.com 75
http://www.slideshare.net 6
http://www.techgig.com 5
http://michaelneale.blogspot.com.au 3
http://michaelneale.blogspot.se 2
http://static.slidesharecdn.com 1
http://michaelneale.blogspot.in 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

SJUG March 2010 Restful design SJUG March 2010 Restful design Presentation Transcript

  • RESTful stuff Michael Neale Red Hat twitter.com/michaelneale www.michaelneale.net
  • What is REST Representational State Transfer (Roy Fielding) Already in use (Kinda) part of the web from day 1
  • What it is not A protocol An interface An API A drop in replacement for SOAP
  • REST is An architectural style Evolved with HTTP 1.1 Nice to use !
  • What is wrong with SOAP? Have to invent protocol (nouns, verbs) for each “service” Every service is different BUT: you can generate stubs Nice? or brittle? Encourages RPC? Is not Simple or about Objects
  • Many SOAP services end up doc-style XML messaging useless: eg MS Sharepoint “xs:any” as payload !
  • What is right with REST Fixed well defined verbs: GET, PUT, POST, DELETE, HEAD ... Focus on resources (not services) Different REST endpoints “feel consistent” Makes “service implementer” work harder
  • Stupid Example The stock ticker
  • Oh FFS
  • REST GET https://service/quote/AAPL
  • Subtleties Content type returned (content type negotiation) What do you do with your spare time?
  • Focus is on data Not services So not a drop in for SOAP/RPC Sometimes people do XML/RPC (but is not RESTful) Sometimes that is cool Can use XSDs for this WADL is silly
  • JAX-RS javax.ws.rs annotations to define paths/resources on POJOs Implementations: RESTEasy, Jersey Part of EE6 (I think??) not web (??)
  • JAX-RS Runs in servlet container use @Path to annotate url paths to POJOs container will create if needed Config in web.xml... boring...
  • Sorry All my real world examples are in scala
  • GET http://myhost.com/services/ library/books GET http://myhost.com/services/ library/book/333 PUT http://myhost.com/services/ library/book/333 DELETE http://myhost.com/services/ library/book/333
  • Content Negotiation
  • In Theory... Annotate pojos but in practice: tend to tailor for REST Use Response object Helper methods Still easy
  • Some more theory GET, PUT, DELETE meant to be idempotent POST is powerful (and easily abused) Use HTTP standard headers Accept (content) ETags for cache control Lots are in HTTP (frameworks help you out)
  • Content type http://www.iana.org/assignments/ media-types/ Media types (MIME types) important for payloads eg application/json, text/html etc Use content negotiation to select appropriate for client
  • Useful formats JSON XML (XSD?) x-www-form-urlencoded (for name/value pairs) html (can just be collection of links !)
  • Content negotiation Simple theory: Client sets Accept (with preference) Server (jax-rs) uses @Produces Are other ways Complex to hand-roll
  • Client side No specific dependencies Just a http client Sometimes can generate stubs but would need XSDs etc RESTEasy has some tools
  • Web clients Can use direct from ajax Modulo support for PUT, DELETE Or treat the web view tier as “client” to RESTful api
  • HATEOAS Hypermedia as the engine of application state Basically: use links when GET: <link href=’/someotherresource’/> Should only have one entry point (URL) and rest discovered (via links - hypermedia !) Honour Accept header/media types
  • No client side URL construction GET deltacloud/api -->
  • Sitebricks jax-rs/RESTEasy to heavy for some some design mistakes As it is a spec, we are SOL So consider sitebricks (shit bricks?)
  • Can everything fit In RESTful design? Probably not. XML-RPC sometimes handy SOAP is overkill, always.
  • Thanks http://jboss.org/resteasy http://code.google.com/p/google- sitebricks/