REST, Atom, OpenSocial, and Friends Alexandros Marinos [email_address]

I read way too much…

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.

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.

http://friendfeed.com/alexandros

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

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

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

Business Architecture?

SOA!

Technical Architectural Style?

SOA!

And what do we implement it with?

Web Services!

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

Business Architecture?

SOA

Technical Architectural Style?

RPC

Implementation?

WS-* Stack

(SOAP, WSDL, UDDI, WS-…)

http://en.wikipedia.org/wiki/WS-*

Disambiguating SOA Business Architecture? SOA. Technical Architectural Style? REST Implementation? HTTP, URI, XML

Business Architecture?

SOA.

Technical Architectural Style?

REST

Implementation?

HTTP, URI, XML

Disambiguating SOA

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

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

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

Other Contrasts:

Top-Down vs. Bottom-Up

Resource-orientation vs. Endpoint-Orientation

Again, Enterprise vs. web origins.

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.

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.

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.

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.

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

Enter this in your browser:

http://www.youtube.com/user/openmicman

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

Now, try this:

http://gdata.youtube.com/feeds/users/openmicman

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

Give every “thing” an ID

Link things together

Use standard methods

Communicate statelessly

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

http://gdata.youtube.com/feeds/users/openmicman

http://gdata.youtube.com/feeds/users/openmicman/favorites

http://www.youtube.com/watch?v=6aKe5baPJCQ

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?

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?

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>

<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>

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)

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)

Example: WS-Style

Example: REST-Style

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

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

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/

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/

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

Google

GData, OpenSocial

Standards

Atom, WebDAV

Amazon

S3, SimpleDB

Microsoft (!)

Project Astoria, Web3S

Um… the Web.

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.

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.

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

Open Competitor to Facebook’s Application Platform

Exposes Three RESTful APIs:

People and Friends data API

Activities data API

Persistence data API

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

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

Questions?

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 )

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 )

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.

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.

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)

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)

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

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