Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

REST Presentation

10,476 views

Published on

OPAALS Comp/Soc meeting day 2

Published in: Technology
  • Excellent slideshow about the need to innovate company models; the way to represent them succinctly; and the desire to make advancement initiatives actionable. Excellent use of images as well as obvious to see illustrative examples.
    Sharika
    http://winkhealth.com http://financewink.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

REST Presentation

  1. 1. REST, Atom, OpenSocial, and Friends Alexandros Marinos [email_address]
  2. 2. I read way too much…
  3. 3. Social Resource Consumption <ul><li>I consume content by a lot of sources, in many formats. (Web, Feeds, YouTube, Amazon, Flickr, etc.) </li></ul><ul><li>I share things I find interesting by exposing a Feed, through Google Reader, Facebook, and FriendFeed. </li></ul><ul><li>The people who read my feed may share the content with their contacts as well. </li></ul>
  4. 4. http://friendfeed.com/alexandros
  5. 5. SOA? <ul><li>If this sounds like SOA, where are the WSDL, SOAP, UDDI in all this? </li></ul><ul><li>This scenario is actually based on HTTP, RSS, Atom, XML and URI. </li></ul><ul><li>There is more than one way to do SOA </li></ul>
  6. 6. Disambiguating SOA <ul><li>Business Architecture? </li></ul><ul><li>SOA! </li></ul><ul><li>Technical Architectural Style? </li></ul><ul><li>SOA! </li></ul><ul><li>And what do we implement it with? </li></ul><ul><li>Web Services! </li></ul>
  7. 7. Disambiguating SOA <ul><li>Business Architecture? </li></ul><ul><ul><li>SOA </li></ul></ul><ul><li>Technical Architectural Style? </li></ul><ul><ul><li>RPC </li></ul></ul><ul><li>Implementation? </li></ul><ul><ul><li>WS-* Stack </li></ul></ul><ul><ul><ul><li>(SOAP, WSDL, UDDI, WS-…) </li></ul></ul></ul><ul><ul><ul><li>http://en.wikipedia.org/wiki/WS-* </li></ul></ul></ul>
  8. 8. Disambiguating SOA <ul><li>Business Architecture? </li></ul><ul><ul><li>SOA. </li></ul></ul><ul><li>Technical Architectural Style? </li></ul><ul><ul><li>REST </li></ul></ul><ul><li>Implementation? </li></ul><ul><ul><li>HTTP, URI, XML </li></ul></ul>
  9. 9. Disambiguating SOA
  10. 10. Disambiguating SOA <ul><li>We have two competing styles, arising from different areas of practice. </li></ul><ul><li>To make an oversimplification: </li></ul><ul><ul><li>WS-* started as enterprise technologies and attempts to scale to the web </li></ul></ul><ul><ul><li>(Previously: CORBA) </li></ul></ul><ul><ul><li>REST started as web technologies and claims to be able to satisfy enterprise requirements </li></ul></ul>
  11. 11. Disambiguating SOA <ul><li>Other Contrasts: </li></ul><ul><ul><li>Top-Down vs. Bottom-Up </li></ul></ul><ul><ul><li>Resource-orientation vs. Endpoint-Orientation </li></ul></ul><ul><ul><ul><li>Again, Enterprise vs. web origins. </li></ul></ul></ul>
  12. 12. What is REST Not? <ul><li>REST is agnostic to the underlying network architecture (P2P or Client-Server). </li></ul><ul><li>It is only concerned with the interface that services expose and are accessed through. </li></ul>
  13. 13. What is REST? <ul><li>An Architectural Style (Such as RPC) </li></ul><ul><li>A way to decompose an application into smaller parts, so that the whole works better in a distributed setting. </li></ul><ul><li>A proven design pattern for building loosely-coupled, highly-scalable applications. </li></ul>
  14. 14. A Little REST Magic <ul><li>Enter this in your browser: </li></ul><ul><li>http://www.youtube.com/user/openmicman </li></ul>
  15. 15. A Little REST Magic <ul><li>Now, try this: </li></ul><ul><li>http://gdata.youtube.com/feeds/users/openmicman </li></ul>
  16. 16. Key REST Principles <ul><li>Give every “thing” an ID </li></ul><ul><li>Link things together </li></ul><ul><li>Use standard methods </li></ul><ul><li>Communicate statelessly </li></ul>
  17. 17. Give every “thing” an ID <ul><li>http://gdata.youtube.com/feeds/users/openmicman </li></ul><ul><li>http://gdata.youtube.com/feeds/users/openmicman/favorites </li></ul><ul><li>http://www.youtube.com/watch?v=6aKe5baPJCQ </li></ul>
  18. 18. Give every “thing” an ID <ul><li>Resources are not only represented as XML </li></ul><ul><li>XML formats (HTML, XHTML, RSS, etc.) </li></ul><ul><li>JPG, GIF, PNG </li></ul><ul><li>MP3, WAV, OGG </li></ul><ul><li>Anything else that can be on the web. </li></ul><ul><li>Thomas: maybe Resources = Knowledge Services? </li></ul>
  19. 19. Link things together <ul><li><order self='http://example.com/customers/1234' > <amount>23</amount> <product ref='http://example.com/products/4554' /> <customer ref='http://example.com/customers/1234' /> </li></ul><ul><li></order> </li></ul>
  20. 20. Use standard methods <ul><li>GET </li></ul><ul><ul><li>Properties: Safe, Idempotent </li></ul></ul><ul><ul><li>Usage: Retrieving a resource </li></ul></ul><ul><li>PUT </li></ul><ul><ul><li>Properties: Idempotent </li></ul></ul><ul><ul><li>Usage: Creating or updating a resource at a known URI </li></ul></ul><ul><li>DELETE </li></ul><ul><ul><li>Properties: Idempotent </li></ul></ul><ul><ul><li>Usage: Deleting a resource </li></ul></ul><ul><li>POST </li></ul><ul><ul><li>Properties: UNSAFE </li></ul></ul><ul><ul><li>Creating a resource within a collection (URI set by server) </li></ul></ul>
  21. 21. Example: WS-Style
  22. 22. Example: REST-Style
  23. 23. Communicate statelessly <ul><li>REST mandates that state be either turned into resource state, or kept on the client. </li></ul><ul><li>Reduces burden on the server </li></ul><ul><li>Reduces coupling with a specific machine </li></ul>
  24. 24. Suitability for Mobile Devices <ul><li>By using REST over HTTP instead of SOAP, we can drastically reduce the overhead of message processing </li></ul><ul><li>An HTTP server implementation is feasible for a mobile device </li></ul><ul><li>http://opensource.nokia.com/projects/mobile-web-server/ </li></ul>
  25. 25. Who is using REST? <ul><li>Google </li></ul><ul><ul><li>GData, OpenSocial </li></ul></ul><ul><li>Standards </li></ul><ul><ul><li>Atom, WebDAV </li></ul></ul><ul><li>Amazon </li></ul><ul><ul><li>S3, SimpleDB </li></ul></ul><ul><li>Microsoft (!) </li></ul><ul><ul><li>Project Astoria, Web3S </li></ul></ul><ul><li>Um… the Web. </li></ul>
  26. 26. Atom <ul><li>Atom Syndication Format </li></ul><ul><ul><li>A Feed specification based on RSS 2.0 </li></ul></ul><ul><li>Atom Publishing Protocol </li></ul><ul><ul><li>a simple HTTP-based protocol for creating and updating web resources. </li></ul></ul>
  27. 27. Google OpenSocial <ul><li>Open Competitor to Facebook’s Application Platform </li></ul><ul><li>Exposes Three RESTful APIs: </li></ul><ul><ul><li>People and Friends data API </li></ul></ul><ul><ul><li>Activities data API </li></ul></ul><ul><ul><li>Persistence data API </li></ul></ul>
  28. 28. REST Resources <ul><li>RESTful Web Services (2007) – Leonard Richardson and Sam Ruby – O’Reilly </li></ul><ul><li>Roy T. Fielding‘s PhD Thesis: “Architectural Styles and the Design of Network-Based Software Architectures” </li></ul><ul><li>A Brief Introduction to REST by Stefan Tilkov </li></ul><ul><li>http://www.infoq.com/articles/rest-introduction </li></ul>
  29. 29. Questions?
  30. 30. REST Constraints <ul><li>REST has four architectural constraints: </li></ul><ul><li>separation of resource from representation, </li></ul><ul><li>uniform interface, </li></ul><ul><li>self-descriptive messages, and </li></ul><ul><li>hypermedia as the engine of application state. </li></ul><ul><li>( http://www.stucharlton.com/blog/archives/000141.html ) </li></ul>
  31. 31. Resource Oriented Architecture? <ul><li>ROA is the term for REST on HTTP/URI </li></ul><ul><li>A Service consists of all the resources available within a certain domain of control </li></ul><ul><li>Since REST is a type of SOA, ROA is an implementation of SOA as well. </li></ul>
  32. 32. REST <ul><li>Important ‘things’ (nouns) are Resources </li></ul><ul><ul><li>Addressed through a URI </li></ul></ul><ul><li>Uniform interface (verbs) </li></ul><ul><ul><li>In HTTP: GET, PUT, POST, DELETE </li></ul></ul><ul><li>Verb-noun seperation makes integration easier </li></ul><ul><ul><li>GET /customer/45 </li></ul></ul><ul><ul><li>Instead of getCustomer(45) OR viewCustomer(45) OR showCustomer(45) </li></ul></ul>
  33. 33. HTTP Verbs <ul><li>GET </li></ul><ul><ul><li>Properties: Safe, Idempotent </li></ul></ul><ul><ul><li>Usage: Retrieving a resource </li></ul></ul><ul><li>POST </li></ul><ul><ul><li>Properties: UNSAFE </li></ul></ul><ul><ul><li>Creating a resource within a collection (resource URI unknown) </li></ul></ul><ul><li>PUT </li></ul><ul><ul><li>Properties: Idempotent </li></ul></ul><ul><ul><li>Usage: Creating or updating a resource at a known URI </li></ul></ul><ul><li>DELETE </li></ul><ul><ul><li>Properties: Idempotent </li></ul></ul><ul><ul><li>Usage: Deleting a resource </li></ul></ul>

×