REST Presentation

Slide 1: REST, Atom, OpenSocial, and Friends Alexandros Marinos a.marinos@surrey.ac.uk

Slide 2: I read way too much… 2

Slide 3: Social Resource Consumption • I consume content by a lot of sources, in many formats. (Web, Feeds, YouTube, Amazon, Flickr, etc.) • I share things I find interesting by exposing a Feed, through Google Reader, Facebook, and FriendFeed. • The people who read my feed may share the content with their contacts as well. 3

Slide 4: http://friendfeed.com/alexandros 4

Slide 5: SOA? • If this sounds like SOA, where are the WSDL, SOAP, UDDI in all this? • This scenario is actually based on HTTP, RSS, Atom, XML and URI. • There is more than one way to do SOA 5

Slide 6: Disambiguating SOA • Business Architecture? • SOA! • Technical Architectural Style? • SOA! • And what do we implement it with? • Web Services! 6

Slide 7: Disambiguating SOA • Business Architecture? – SOA • Technical Architectural Style? – RPC • Implementation? – WS-* Stack (SOAP, WSDL, UDDI, WS-…) http://en.wikipedia.org/wiki/WS-* 7

Slide 8: Disambiguating SOA • Business Architecture? – SOA. • Technical Architectural Style? – REST • Implementation? – HTTP, URI, XML 8

Slide 9: Disambiguating SOA SOA HTTP SOAP URI WSDL XML UDDI ... WS - ... REST WS-* 9

Slide 10: Disambiguating SOA • We have two competing styles, arising from different areas of practice. • To make an oversimplification: – WS-* started as enterprise technologies and attempts to scale to the web (Previously: CORBA) – REST started as web technologies and claims to be able to satisfy enterprise requirements 10

Slide 11: Disambiguating SOA • Other Contrasts: – Top-Down vs. Bottom-Up – Resource-orientation vs. Endpoint-Orientation • Again, Enterprise vs. web origins. 11

Slide 12: What is REST Not? • REST is agnostic to the underlying network architecture (P2P or Client-Server). • It is only concerned with the interface that services expose and are accessed through. 12

Slide 13: What is REST? • An Architectural Style (Such as RPC) • A way to decompose an application into smaller parts, so that the whole works better in a distributed setting. • A proven design pattern for building loosely-coupled, highly-scalable applications. 13

Slide 14: A Little REST Magic Enter this in your browser: http://www.youtube.com/user/openmicman 14

Slide 15: A Little REST Magic Now, try this: http://gdata.youtube.com/feeds/users/openmicman 15

Slide 16: Key REST Principles • Give every “thing” an ID • Link things together • Use standard methods • Communicate statelessly 16

Slide 17: Give every “thing” an ID http://gdata.youtube.com/feeds/users/openmicman http://gdata.youtube.com/feeds/users/openmicman/fa http://www.youtube.com/watch?v=6aKe5baPJCQ 17

Slide 18: Give every “thing” an ID Resources are not only represented as XML • XML formats (HTML, XHTML, RSS, etc.) • JPG, GIF, PNG • MP3, WAV, OGG • Anything else that can be on the web. • Thomas: maybe Resources = Knowledge Services? 18

Slide 19: Link things together <order self='http://example.com/customers/1234' > <amount>23</amount> <product ref='http://example.com/products/4554' /> <customer ref='http://example.com/customers/1234' /> </order> 19

Slide 20: Use standard methods • GET – Properties: Safe, Idempotent – Usage: Retrieving a resource • PUT – Properties: Idempotent – Usage: Creating or updating a resource at a known URI • DELETE – Properties: Idempotent – Usage: Deleting a resource • POST – Properties: UNSAFE – Creating a resource within a collection (URI set by server) 20

Slide 21: Example: WS-Style 21

Slide 22: Example: REST-Style 22

Slide 23: Communicate statelessly • REST mandates that state be either turned into resource state, or kept on the client. • Reduces burden on the server • Reduces coupling with a specific machine 23

Slide 24: Suitability for Mobile Devices • By using REST over HTTP instead of SOAP, we can drastically reduce the overhead of message processing • An HTTP server implementation is feasible for a mobile device http://opensource.nokia.com/projects/mobile-web-server/ 24

Slide 25: Who is using REST? • Google – GData, OpenSocial • Standards – Atom, WebDAV • Amazon – S3, SimpleDB • Microsoft (!) – Project Astoria, Web3S • Um… the Web. 25

Slide 26: Atom • Atom Syndication Format – A Feed specification based on RSS 2.0 • Atom Publishing Protocol – a simple HTTP-based protocol for creating and updating web resources. 26

Slide 27: Google OpenSocial • Open Competitor to Facebook’s Application Platform • Exposes Three RESTful APIs: – People and Friends data API – Activities data API – Persistence data API 27

Slide 28: REST Resources • RESTful Web Services (2007) – Leonard Richardson and Sam Ruby – O’Reilly • Roy T. Fielding‘s PhD Thesis: “Architectural Styles and the Design of Network-Based Software Architectures” • A Brief Introduction to REST by Stefan Tilkov http://www.infoq.com/articles/rest-introduction 28

Slide 29: Questions? 29

Slide 30: REST Constraints REST has four architectural constraints: • separation of resource from representation, • uniform interface, • self-descriptive messages, and • hypermedia as the engine of application state. (http://www.stucharlton.com/blog/archives/000141.html ) 30

Slide 31: Resource Oriented Architecture? • ROA is the term for REST on HTTP/URI • A Service consists of all the resources available within a certain domain of control • Since REST is a type of SOA, ROA is an implementation of SOA as well. 31

Slide 32: REST • Important ‘things’ (nouns) are Resources – Addressed through a URI • Uniform interface (verbs) – In HTTP: GET, PUT, POST, DELETE • Verb-noun seperation makes integration easier – GET /customer/45 Instead of getCustomer(45) OR viewCustomer(45) OR showCustomer(45) 32

Slide 33: HTTP Verbs • GET – Properties: Safe, Idempotent – Usage: Retrieving a resource • POST – Properties: UNSAFE – Creating a resource within a collection (resource URI unknown) • PUT – Properties: Idempotent – Usage: Creating or updating a resource at a known URI • DELETE – Properties: Idempotent – Usage: Deleting a resource 33