Modified REST Presentation

1,613 views

Published on

OPAALS Comp/Soc meeting day 4

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,613
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Modified REST Presentation

  1. 1. REpresentational State Transfer 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. Disambiguating SOA
  6. 6. 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>
  7. 7. 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>
  8. 8. 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>
  9. 9. What is REST? <ul><li>An Architectural Style (Such as RPC), Essentially a set of principles. </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>
  10. 10. A Little REST Magic <ul><li>Enter this in your browser: </li></ul><ul><li>http://www.youtube.com/user/openmicman </li></ul>
  11. 11. A Little REST Magic <ul><li>Now, try this: </li></ul><ul><li>http://gdata.youtube.com/feeds/users/openmicman </li></ul>
  12. 12. 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>
  13. 13. 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>
  14. 14. 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>
  15. 15. 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>
  16. 16. Example: WS-Style
  17. 17. Example: REST-Style
  18. 18. 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>
  19. 19. 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>
  20. 20. 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>
  21. 21. 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>
  22. 22. An Idea <ul><li>Many of us use web applications (Feed Readers, Photo Sharing, Social Bookmaring, Lifestreaming) </li></ul><ul><li>Therefore we are sharing feeds of various things (Articles, Photos, Favourites, Status Updates) </li></ul><ul><li>That is a lot of data on a bottom-up knowledge space that is forming. </li></ul>
  23. 23. An Idea <ul><li>It would be interesting to learn what these feeds are </li></ul><ul><li>Resources will reoccur or propagate from feed to feed </li></ul><ul><li>this may form patterns which may be interesting from a practical or theoretical point of view </li></ul>
  24. 24. Questions?
  25. 25. 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>
  26. 26. 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>
  27. 27. 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>
  28. 28. 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>
  29. 29. 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>
  30. 30. 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>
  31. 31. 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>
  32. 32. 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>
  33. 33. 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>
  34. 34. 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>
  35. 35. 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>

×