Representational StateTransfer (REST) Paul Townend

8th February 2007

What is REST? (I)

REST is an architectural style for distributed hypermedia systems.

REpresentational State Transfer.

The term originated in a year 2000 PhD thesis by Roy Fielding.

REST states that the existing principles and protocols of the web are enough to create robust Web Services – you don’t need SOAP.

What does it consist of? (I)

REST is a very simple architecture:

Application state and functionality is divided into resources.

Every resource is uniquely addressable using a universal syntax for use in hypermedia links.

All resources share a uniform interface for the transfer of state between a client and a resource.

What does it consist of? (II)

The uniform interface features a constrained set of well-defined operations and a constrained set of content types.

REST uses a protocol that is client/server, stateless, cacheable and layered.

The REST methodology is identical to the way in which a Web browser gets Web pages from or posts to a web server.

An example...

In practice... (I)

A web page is a resource. So is a jpeg picture file located on that web page. So are any links, sound files, etc.

Resources are accessible using a universal syntax – the URI.

With REST, URIs are assigned to individual data records, customer records, and orders, as transferred between a Web Service and a Client.

In practice... (II)

The well-defined operations supported by REST resources are simply HTTP verbs, the most important of which are GET, POST, PUT and DELETE.

These operations are used to issue a request to a REST Web Service to access and manipulate the server-side state, or data record, identified by the URI.

In practice... (III)

These verbs can be seen as being similar to the cut and paste paradigm, and also to the CRUD operations associated with DBMS.

GET = READ or COPY

PUT = UPDATE or PASTE OVER

POST = CREATE or PASTE AFTER

DELETE = DELETE or CUT

REST

Nouns(unconstrained)

e.g. http://www.google.com/

Verbs(constrained)

e.g. GET

Content types(constrained)

e.g. HTML

The “REST triangle”

REST is not a standard – it’s an architectural style, although it does prescribe the use of standards (HTTP, URI, XML/HTML/JPEG etc)

An example

An example (I)

I’ll now show an example of a RESTful service – this is stolen from www.xfront.com

Consider a Parts Depot Web Service, which allows its customers to:

Get a list of parts Get detailed information about a particular part Submit a purchase order (PO)

An example (II)

An example (III)

Get a list of parts

A RESTful web service makes a URI available to its parts list resource. So you’d access something like:

http://www.parts-depot.com/parts

If the service wishes to specify what type of document the user wants…

http://www.parts-depot.com/parts?flavour=xml

An example (IV)

An example (V)

Get information about a particular part

The RESTful Web Service makes available a URI to each part resource, such as:http://www.parts-depot.com/parts/00345?flavour=xml

This is a logical URI – it expresses what resource is desired. It is not a physical object. You don’t need a million HTML pages if you have a million parts.

An example (VI)

An example (VII)

Reiteration

As can be seen from the example, RESTful services feature:

Client/Server interaction style Stateless requests Cache: responses can be marked cacheable

or otherwise Uniform interface: GET, POST, etc. Named resources: URIs Interconnected resource representations

Claimed Benefits (I)

Advocates of REST claim:

Provides improved response times due to support for caching

Improves server scalability by reducing the need to maintain communication state (i.e. different servers can handle initial and subsequent requests).

Depends less on vendor software than mechanisms that layer additional messaging frameworks on top of HTTP (such as SOAP)

Claimed Benefits (II)

Provides equivalent functionality when compared to alternative approaches to communication

Does not require a separate resource discovery mechanism due to use of hyperlinks in content.

Provides better long term compatibility and evolvability characteristics than RPC:

capability of document types like HTML to evolve without breaking backwards or forwards compatibility

Ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types

Parts Depot with SOAP

REST / SOAP (I)

SOAP and REST are essentially the same in what they do, but different in how they work.

Both methods allow programs to exchange XML messages over a network.

I shall now detail some differences…

REST / SOAP (II)

A SOAP server must look inside a SOAP envelope to find the target resource. With REST, all decisions are based on the URI and HTTP method.

If an organisation has a proxy server (or gateway, cache, etc.) that filters out certain URIs, a RESTful interaction can be analysed much more easily, whilst with SOAP the envelope would need to be inspected, and the proxy would have to understand the semantics of every SOAP application.

REST / SOAP (III)

In a network-based application, communications are often a bottleneck. With REST, resources can be cached locally.

Conversely, when submitting a SOAP message, HTTP POST is used, so a cache server will not know from the HTTP method whether a client is doing a request. Also, the SOAP URI is always the SOAP server.

So no caching is possible with SOAP.

REST / SOAP (IV)

REST is consistent with the vision of the semantic web (every resource has a logical URI).

SOAP URIs are funneled through a single URI to the SOAP server – not consistent.

REST has a generic interface; SOAP has no defined set of methods.

Consequently, tools must be customised on a per-application basis with SOAP. This is not scalable.

REST / SOAP (V)

In terms of interoperability, SOAP depends on much more customisation than REST.

Each SOAP message provides a unique method of naming a resource, and each SOAP application defines its own interface.

REST is based on standards: URIs, HTTP GET/POST/PUT/DELETE, HTML, XML, GIF, MIME, etc.

So proponents argue that REST is more inherently interoperable.

REST / SOAP (VI)

With both REST and SOAP applications, you need prior agreement on data semantics.

However, if the payload is RDF or DAML, the client may be able to dynamically learn the meaning of the response data.

With REST, there are links to the next state built into every link response; with dynamic learning of response data + dynamic reasoning of link traversals, self-reasoning automata may be possible!

Conclusions (I)

REST is simple, and is also cost-effective and highly scalable.

There is a big debate in the WS community about whether to use REST/SOAP.

Amazon report that usage of their web services is 80% REST, and 20% SOAP.

SOAP cannot be utilised by proxy serves, cache servers, etc.

Conclusions (II)

Some argue that SOAP is best used only in closed systems.

REST is growing in popularity primarily due to its ease of implementation.

REST is considered to be faster than SOAP (Amazon claim that REST is up to six times faster)

Conclusions (III)

I have heard arguments that REST is very attractive for basic applications that involve high levels of interoperability between multiple platforms.

And SOAP is appropriate for larger, formal applications that require advanced capabilities between relatively homogenous systems.

SOAP has rich functionality but at the expense of interoperability.

Final comparisons - REST

REST

Messages represented in plain XML HTTP used as transfer protocol HTTP verbs used for access/manipulation URIs are used to uniquely identify resources HTTP authentication used for security No formal method for expressing interface

content

Final comparisons - SOAP

SOAP

Messages are represented in a standardised XML SOAP envelope.

Can be bound to different protocols (i.e. HTTP, SMTP) Access/manipulation of data is application specific. Security is not described by SOAP and is to be

provided by the developer. XML schemas used to define contract between the

Client and the Service.