REST Presentation

7,443 views
7,065 views

Published on

OPAALS Comp/Soc meeting day 2

Published in: Technology
1 Comment
3 Likes
Statistics
Notes
  • 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
No Downloads
Views
Total views
7,443
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
246
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

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>

×