SJUG March 2010 Restful design


Published on

Sydney Java Users Group - RESTful design explained

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • SJUG March 2010 Restful design

    1. 1. RESTful stuff Michael Neale Red Hat
    2. 2. What is REST Representational State Transfer (Roy Fielding) Already in use (Kinda) part of the web from day 1
    3. 3. What it is not A protocol An interface An API A drop in replacement for SOAP
    4. 4. REST is An architectural style Evolved with HTTP 1.1 Nice to use !
    5. 5. 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
    6. 6. Many SOAP services end up doc-style XML messaging useless: eg MS Sharepoint “xs:any” as payload !
    7. 7. 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
    8. 8. Stupid Example The stock ticker
    9. 9. Oh FFS
    10. 10. REST GET https://service/quote/AAPL
    11. 11. Subtleties Content type returned (content type negotiation) What do you do with your spare time?
    12. 12. 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
    13. 13. JAX-RS annotations to define paths/resources on POJOs Implementations: RESTEasy, Jersey Part of EE6 (I think??) not web (??)
    14. 14. JAX-RS Runs in servlet container use @Path to annotate url paths to POJOs container will create if needed Config in web.xml... boring...
    15. 15. Sorry All my real world examples are in scala
    16. 16. GET library/books GET library/book/333 PUT library/book/333 DELETE library/book/333
    17. 17. Content Negotiation
    18. 18. In Theory... Annotate pojos but in practice: tend to tailor for REST Use Response object Helper methods Still easy
    19. 19. 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)
    20. 20. Content type media-types/ Media types (MIME types) important for payloads eg application/json, text/html etc Use content negotiation to select appropriate for client
    21. 21. Useful formats JSON XML (XSD?) x-www-form-urlencoded (for name/value pairs) html (can just be collection of links !)
    22. 22. Content negotiation Simple theory: Client sets Accept (with preference) Server (jax-rs) uses @Produces Are other ways Complex to hand-roll
    23. 23. Client side No specific dependencies Just a http client Sometimes can generate stubs but would need XSDs etc RESTEasy has some tools
    24. 24. Web clients Can use direct from ajax Modulo support for PUT, DELETE Or treat the web view tier as “client” to RESTful api
    25. 25. 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
    26. 26. No client side URL construction GET deltacloud/api -->
    27. 27. Sitebricks jax-rs/RESTEasy to heavy for some some design mistakes As it is a spec, we are SOL So consider sitebricks (shit bricks?)
    28. 28. Can everything fit In RESTful design? Probably not. XML-RPC sometimes handy SOAP is overkill, always.
    29. 29. Thanks sitebricks/