The Rest Architectural Style
Upcoming SlideShare
Loading in...5
×
 

The Rest Architectural Style

on

  • 10,650 views

Introduction to the REST architectural style with an example API - SOFT

Introduction to the REST architectural style with an example API - SOFT

Statistics

Views

Total Views
10,650
Views on SlideShare
9,967
Embed Views
683

Actions

Likes
13
Downloads
506
Comments
1

6 Embeds 683

http://abrdev.com 548
http://blogdojoellobo.blogspot.com 99
http://www.slideshare.net 23
http://www.techgig.com 7
http://blogdojoellobo.blogspot.com.br 5
http://blogdojoellobo.blogspot.pt 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

The Rest Architectural Style Presentation Transcript

  • 1. The REST Architectural Style Robert Wilson, March 2009 [email_address]
  • 2.
      • Who has heard of REST ?
  • 3. REST is
    • An acronym from: Representational State Transfer
    • An architectural style that is derived by applying a set constraints to the elements of a system so the system exhibits certain properties such as loose coupling and scalability
    • Defined by Roy T. Fielding, PhD in his PhD dissertation, Chapter 5 Representational State Transfer (REST) ‏
    • Data-orientated, “ Unlike the distributed object style [ 31 ], where all data is encapsulated within and hidden by the processing components, the nature and state of an architecture's data elements is a key aspect of REST” Architectural Styles and the Design of Network-based Software Architectures Roy Thomas Fielding, 2000: PhD dissertation, Chapter 5 Representational State Transfer (REST)
  • 4. When can I use REST?
    • For Web Services
      • build your web service using the REST style
      • alternative to some of WS-*, not a replacement for WS-*
    • Clients interfacing to public REST APIs
      • e.g. Amazon S3 REST API, Google Data APIs
      • 63 percent public APIs have a REST like interface http://www.infoq.com/presentations/Open-API-John-Musser
    • From Rich Internet Applications (RIAs) ‏
      • client sends AJAX requests to a REST interface using a JavaScript library e.g. jQuery, Dojo (JsonRestStore) or a framework like JavaFX or Silverlight
      • response (JSON, XML etc) is displayed on the client
  • 5. R & R
    • Resources r
      • an abstraction of information: a thing, an entity, an event or “any information that can be named”
      • identified by URIs, URIs should contain nouns, not verbs
    • Representations r
      • information retrieved from a resource
      • resource data plus meta-data with control data (in HTTP this is the message content and headers) ‏
      • possible in more than one media type, i.e. a resource could be represented in HTML, XML, JSON, Atom, XHTML or RDF
      • the current resource state containing data and possibly URIs (links). The URIs are the relationships and application state transitions available from the current representation
  • 6. The REST Constraints
    • Client-Server architectural style
    • Stateless Server
      • session state is kept on the client
    • Cacheable
      • data is labelled as cacheable or non-cacheable
  • 7. The REST Constraints cont.
    • The Uniform interface is
      • “ The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components” Architectural Styles and the Design of Network-based Software Architectures Roy Thomas Fielding, 2000: PhD dissertation, Chapter 5 Representational State Transfer (REST)
      • for manipulating resources via URIs through a generic set of methods. A uniform interface reduces coupling compared to a services specific interface specification
  • 8. The REST Constraints cont.
    • The Uniform interface is
      • composed of four constraints:
        • identification of resources
        • manipulation of resources through representations
        • self-descriptive messages – meta data & control data
        • hypermedia as the engine of application state - “the hypertext constraint” , i.e. links in the data for navigation through the application. This is one of the most important constraints
  • 9. The REST Constraints cont.
    • Layered system
    • Code-On-Demand – “optional constraint”
      • client functionality extended through download of code or scripts
    • The constraints will likely have design trade-offs, for example
      • caching may improve performance but decrease reliability if stale data is served
      • a stateless server can increase information in each message & you now need to rely on the client to maintain state
  • 10. Web uniform interface semantics
    • RFC2616 specifies HTTP intended method behaviour and semantics for common HTTP methods
    • Safe: no side-effects, e.g. does not change resource
    • Idempotent: “the side-effects of N > 0 identical requests is the same as for a single request”
    Method Operation on the resource Safe Idempotent POST create a new resource as subordinate No No GET retrieve a resource representation Yes Yes PUT modify (update) a resource or create a resource at the id No Yes DELETE delete a resource No Yes
  • 11. Web API using REST principles
    • Define the resources
    • Design the resource representations
    • HTTP Protocol considerations
      • response status codes
      • caching strategy
      • encodings
    • Security
  • 12. Walk through beginnings of SOFT
    • SOFT – Simple Online Family Tree
    • Fictitious new web service
    • Walk through part of the design of the Web API
  • 13. Web API using REST principles
    • Define the resources
    • Design the resource representations
    • HTTP Protocol considerations
      • response status codes
      • caching strategy
      • encodings
    • Security
  • 14. SOFT resources
    • Candidate resources are:
    family-trees mother family-tree father people brother person sister relations spouse relation siblings children child
  • 15. Web API using REST principles
    • Define the resources
    • Design the resource representations
    • HTTP Protocol considerations
      • response status codes
      • caching strategy
      • encodings
    • Security
  • 16. SOFT Resource Representations
    • Lets elicit some of them by working through example scenarios of request response messages across the uniform interface
    • Our initial URL will be
      • http://soft.example.org/family-trees
    • The server will create the hierarchy underneath this URL so client does not need to know the structure as it will be given it by the server in the representations – this avoids coupling between client & server over the hierarchy structure
  • 17. SOFT Resource Representations
    • First off create a family-tree with the request:
        • POST /family-trees HTTP 1.1
        • Host: soft.example.org
        • Content-Type: application/xml
        • Content-Length: …
        • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
        • <familyTree xmlns=&quot;http://soft.example.org/family-trees&quot; >
        • <name>The Addams Family Tree</name>
        • <createdBy>Gomez Addams</createdBy>
        • </familyTree>
    • Response:
        • 201 Created
        • Location: http://soft.example.org/family-trees/0008
        • Content-Type: application/xml
        • Content-Length: …
        • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
        • <familyTree xmlns=&quot;http://soft.example.org/family-trees&quot; xml:base=&quot;http://soft.example.org/family-trees/0008/&quot;>
        • <name>The Addams Family Tree</name>
        • <createdBy>Gomez Addams</createdBy>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;&quot; title=&quot;FamilyTree&quot;/>
        • <link rel=&quot;related&quot; type=&quot;application/xml&quot; href=&quot;people&quot; title=&quot;People&quot;/>
        • </familyTree>
  • 18. Resource Representations cont.
        • In the previous response the link element with the edit attribute is for editing, the href is relative to xml:base ( the link element is borrowed from the atom:link element)
    • From the previous response using the link element with the title attribute “People”, its relative href & the xml:base attribute we can now create an initial person with the request:
        • POST /family-trees/0008/people HTTP 1.1
        • Host: soft.example.org
        • Content-Type: application/xml
        • Content-Length: …
        • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
        • <person xmlns=&quot;http://soft.example.org/family-trees&quot;>
        • <firstName>Morticia</firstName>
        • <lastName>Addams</lastName>
        • <birth>19800101</birth>
        • <sex>F</sex>
        • </person>
  • 19. Resource Representations cont.
    • Response:
        • 201 Created
        • Location: http://soft.example.org/family-trees/0008/people/1234
        • Content-Type: application/xml
        • Content-Length: …
        • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
        • <person xmlns=&quot;http://soft.example.org/family-trees&quot;
        • xml:base &quot;http://soft.example.org/family-trees/0008/people/1234/&quot;>
        • <firstName>Morticia</firstName>
        • <lastName>Addams</lastName>
        • <birth>19800101</birth>
        • <sex>F</sex>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;&quot; title=&quot;Person&quot;/>
        • <link rel=&quot;related&quot; type=&quot;application/xml&quot; href=&quot;relations&quot; title=&quot;Relations&quot;/>
        • </person>
        • with link elements for editing Morticia and Morticia’s relations
  • 20. Resource Representations cont.
    • After creating two extra people who are Morticia’s mother and brother, add them as relations of Moritica:
        • POST /family-trees/0008/people/1234/relations HTTP 1.1
        • Host: soft.example.org
        • Content-Type: application/x-www-form-urlencoded
        • Content-Length: …
        • role=mother&person=http://soft.example.org/family-trees/0008/people/2344
        • 201 Created
        • Location: http://soft.example.org/family-trees/0008/people/1234/relations/mother
        • Content-Length: 0
        • POST /family-trees/0008/people/1234/relations HTTP 1.1
        • Host: soft.example.org
        • Content-Type: application/x-www-form-urlencoded
        • Content-Length: …
        • role=brother&person=http://soft.example.org/family-trees/0008/people/5588
        • 201 Created
        • Location: http://soft.example.org/family-trees/0008/people/1234/relations/brothers/5588
        • Content-Length: 0
  • 21. Resource Representations cont.
    • If we GET Morticia’s relations using the edit link from the initial Post response using:
        • GET /family-trees/0008/people/1234/relations HTTP 1.1
        • Host: soft.example.org
    • Response:
        • 200 OK
        • Location: http://soft.example.org/family-trees/0008/people/1234/relations
        • Content-Type: application/xml
        • Content-Length: …
        • <relations xmlns=&quot;http://soft.example.org/family-trees&quot;
        • xml:base &quot;http://soft.example.org/family-trees/0008/people/1234/relations/&quot;>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;&quot; title=&quot;Relations&quot;/>
        • <relation role=&quot;mother&quot; person=&quot;http://soft.example.org/family-trees/0008/people/2234&quot;>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;mother&quot; title=&quot;Mother&quot;/>
        • </relation>
        • <relation role=&quot;brother&quot; person=&quot;http://soft.example.org/family-trees/0008/people/5588&quot;>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;brothers/5588&quot; title=&quot;Brother&quot;/>
        • </relation>
        • </relations>
  • 22. Resource Representations cont.
    • Lets modify Morticia’s mother with a PUT request:
        • PUT /family-trees/0008/people/1234/relations/mother HTTP 1.1
        • Host: soft.example.org
        • Content-Type: application/x-www-form-urlencoded
        • Content-Length: …
        • role=mother&person=http://soft.example.org/family-trees/0008/people/5556
    • Response:
        • 200 OK
        • Location: http://soft.example.org/family-trees/0008/people/1234/relations/mother
        • Content-Type: application/xml
        • Content-Length: …
        • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
        • <relation xmlns=&quot;http://soft.example.org/family-trees&quot;
        • xml:base &quot;http://soft.example.org/family-trees/0008/people/1234/relations/mother&quot;
        • role=&quot;mother&quot; person=&quot;http://soft.example.org/family-trees/0008/people/5556&quot;>
        • <link rel=&quot;edit&quot; type=&quot;application/xml&quot; href=&quot;&quot; title=&quot;Mother&quot;/>
        • </relation>
  • 23. Resource Representations cont.
    • Lets delete Morticia’s brother with a DELETE request:
        • DELETE /family-trees/0008/people/1234/relations/brothers/5588 HTTP 1.1
        • Host: soft.example.org
    • Response:
        • 200 OK
  • 24. Web API using REST principles
    • Define the resources
    • Design the resource representations
    • HTTP Protocol considerations
      • response status codes
      • caching strategy
      • encodings
    • Security
  • 25. SOFT response status codes
    • Specify the HTTP method response codes from SOFT
    • POST
      • on success will return 201 Created and the Location: header will have the URI of the new resource
      • failure code: 400 Bad Request
    • GET
      • on success will return 200 OK
      • failure codes: 400 Bad Request, 404 Not Found
  • 26. SOFT response status codes cont.
    • PUT
      • on success will return 200 OK
      • failure codes: 400 Bad Request, 404 Not Found, 409 Conflict
    • DELETE
      • on success will return 200 OK
      • failure codes: 400 Bad Request, 404 Not Found, 410 Gone
    • If security is applied and the user is not authenticated then the response is 401 Unauthorised
    • see Reference for RFC2616, Ch 10 Status Code Definitions
  • 27. Consider SOFT’s Caching Strategy
    • Cache Topology
      • Private Caches – in the Web browser
      • Proxy Caches – proxy server for scalability
    • Cache Processing
      • Server specifies expiration time using Cache-Control (HTTP/1.1) or Expires (HTTP/1.0) headers
      • Revalidation using a “conditional GET”, only gets a new copy of the document if it has changed , client can send either header:
        • If-Modified-Since, send date that client has as Last-Modified date, only resolution to the second
        • If-None-Match, send the ETag value that was sent from the server back to the server to see if the cache stale
  • 28. Consider HTTP Encodings for SOFT
    • Content-Encoding, encoding of the data by
      • compression (gzip ...) , encryption (PGP…)
    • Transfer-Encoding, encoding to change the way the data is transferred:
      • chunked, send the data in chunks , don’t specify a content length
  • 29. Web API using REST principles
    • Define the resources
    • Design the resource representations
    • HTTP Protocol considerations
      • response status codes
      • caching strategy
      • encodings
    • Security
  • 30. SOFT Security
    • Could use
      • basic authentication, need to use HTTPS to encrypt the username password information in the header
      • digest authentication, MD5 checksum of the username, password so these are not sent in clear text
      • HMAC: Keyed-Hashing for Message Authentication , a hash of selected elements from the request with a secret key, used by Amazon
      • http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?RESTAuthentication.html
    • For information that needs to be secure use HTTPS to encrypt the message which ever method above is used. Note: As HTTPS encrypts the message an intermediary will not know to cache the message, i.e. no caching by intermediaries when using HTTPS
  • 31. Worked examples
    • For other examples see the references
      • How to GET a Cup of Coffee by Jim Webber, Savas Parastatidis & Ian Robinson Oct 02, 2008
      • http://www.infoq.com/articles/webber-rest-workflow
      • msdn, A Guide to Designing and Building RESTful Web Services with WCF 3.5, Aaron Skonnard, Oct 2008
      • http://msdn.microsoft.com/en-us/library/dd203052.aspx
      • Using REST to aid WS-* - building a RESTful SOA Registry
      • http://www.infoq.com/presentations/rest-soa-registry
  • 32. Java Toolkits/Frameworks
    • Java Community Process - JSR 311: JAX-RS: The Java TM API for RESTful Web Services , server side specification, annotation based
    • Jersey,
      • Sun production ready reference implementation of JSR311
    • RESTlet
      • early REST framework, implements JSR311 and has its own class based hierarchy
    • RESTEasy from Jboss
      • implements JSR311, also includes a client framework
    • Apache CXF 2.1
  • 33. Java Toolkits/Frameworks cont.
    • Spring MVC 3.0.0M1
      • 3.0.0 is a milestone release, GA in Q2 2009
      • REST was highly requested as a feature to be included in 3.0 by the Spring user community
      • 3.0.0 has better support for REST than the current version
      • can integrate Jersey, RESTEasy, CXF, RESTlet with the current version of Spring
  • 34. Toolkits/Frameworks
    • Microsoft Windows Communication Framework 3.5 (WCF) ‏
    • IBM WebSphere sMash
      • previously know as Project Zero
    • Ruby on Rails
  • 35. Concluding REST
    • Think of the resources:
      • Any information can be a resource
      • Their data format (representations with URIs) and
      • Manipulation through a uniform interface
    • If REST constraints aren’t needed then don’t worry about them. An API that has all the REST constraints is a RESTful API.
  • 36.
    • QUESTIONS?
  • 37. References
    • Architectural Styles and the Design of Network-based Software Architectures Roy Thomas Fielding, 2000: PhD dissertation, Chapter 5 Representational State Transfer (REST) , http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Chapter 6 Experience and Evaluation, http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
    • RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 June 1999, R .Fielding et al.
      • http://www.rfc-editor.org/rfc/rfc2616.txt
    • A little REST and Relaxation, Roy T. Fielding, Ph.D.
      • http://www.slideshare.net/royfielding/a-little-rest-and-relaxation
    • IBM, RESTful Web services: The basics by Alex Rodriguez, 06 Nov 2008
      • http://www.ibm.com/developerworks/webservices/library/ws-restful/index.html
    • How to GET a Cup of Coffee by Jim Webber, Savas Parastatidis & Ian Robinson Oct 02, 2008
      • http://www.infoq.com/articles/webber-rest-workflow
    • REST Anti-Patterns by Stefan Tilkov, http://www.infoq.com/articles/rest-anti-patterns
    • REST: A Pragmatic Introduction to the Web's Architecture by Stefan Tilkov Jan 29 2009
      • http://www.infoq.com/presentations/qcon-tilkov-rest-intro
      • http://www.slideshare.net/deimos/stefan-tilkov-pragmatic-intro-to-rest
    • msdn, A Guide to Designing and Building RESTful Web Services with WCF 3.5, Aaron Skonnard, Oct 2008
      • http://msdn.microsoft.com/en-us/library/dd203052.aspx
    • Ian Robinson discusses REST, WS-* and Implementing an SOA Jan 26, 2009
      • http://www.infoq.com/interviews/robinson-rest-ws-soa-implementation
    • http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
    • http://www.xfront.com/REST.ppt
  • 38. References cont.
    • http://www.slideshare.net/ozten/rest-vs-soap-yawn
    • http://www.slideshare.net/stevenn/devoxx-2008-rest-in-peace-presentation-831560
    • http://www.slideshare.net/sallamar/pragmatic-rest-presentation
    • http://www.slideshare.net/guestb2ed5f/scalable-reliable-secure-rest
    • http://www.slideshare.net/swamy_g/rest-overview
    • http://www.slideshare.net/deimos/steve-vinoski-rest-and-reuse-and-serendipity
    • http://www.slideshare.net/calamitas/restful-best-practices
    • Code Talks: Demonstrating the &quot;ilities&quot; of REST
      • http://wanderingbarque.com/presentations/qcon2007.ppt
    • http://bitworking.org/news/125/REST-and-WS
    • Amazon S3, http://docs.amazonwebservices.com/AmazonS3/latest/RESTAPI.html
    • Google Data API, http://code.google.com/apis/gdata/docs/2.0/basics.html
    • Yahoo Groups: rest-discuss, http://tech.groups.yahoo.com/group/rest-discuss
    • www.infoq.com/rest
    • HTTP :The Definitive Guide by David Gourley, Brian Totty
    • URI Templates
      • http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.html
      • http://www.ibm.com/developerworks/web/library/wa-uri/
      • http://www.ietf.org/rfc/rfc3986.txt
    • http://www.infoq.com/presentations/Open-API-John-Musser
    • http://www.infoq.com/presentations/rest-soa-registry
  • 39. References cont.
    • Jersey related:
      • https://jersey.dev.java.net/ http://weblogs.java.net/blog/caroljmcdonald/ http://blogs.sun.com/theaquarium/tags/Jersey
      • http://wiki.glassfish.java.net/attach/RESTfulWebServicesDevelopersGuide/p6.html
    • REST presentation from the Developing Rich Internet Applications with Spring course by SpringSource
    • http://www.jroller.com/Solomon/entry/jax_rs_spring_integration
    • http://www.codemonkeyism.com/wp-content/uploads/2008/10/web-entwicklung-2008_english.pdf
    • http://www.ibm.com/developerworks/library/i-zero1/
    • http://hinchcliffe.org/archive/2006/09/10/9275.aspx
    • http://www.infoq.com/interviews/Spring-3.0-Rod-Johnson
    • How Ruby on Rails and REST go together By Rich Seeley, News Writer 21 May 2008 | SearchSOA.com
      • http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1314640,00.html
    • Security
      • HTTP Authentication: Basic and Digest Access Authentication, J .Fransks et al. June 1999
        • http://www.ietf.org/rfc/rfc2617.txt
      • http://kswenson.wordpress.com/2008/12/11/rest-assured-oauth-security/
        • http://msdn.microsoft.com/en-us/library/dd203052.aspx
      • Atom
        • The Atom Syndication Format , http://www.ietf.org/rfc/rfc4287.txt
        • The Atom Publishing Protocol , http://www.ietf.org/rfc/rfc5023.txt
        • http://www.ibm.com/developerworks/xml/library/x-atom10.html
    • ancestry.com.au
    • THE END