REST follows resource oriented architecture as opposed to the popular service oriented architecture followed by SOAP web services.

Resource-Oriented Architecture has four important concepts:

• Resources,

• their names (URIs),

• their representations and

• the links between them.

It also has four important properties:

• Addressability,

• Statelessness,

• Connectedness and

• A uniform interface.

Resource and representation

A resource is a source of representations, and a representation is data about the current state of a resource.

For example, most web sites, like javajee.com, make their articles available in a stripped-down “printer-friendly” format or even in PDF format alongside the web page format. These can be considered as different representations of the same resource.

When you interact with REST services you will be doing so using various representations of that service. Representations can flow both directions.

A server will send you the representation of a resource in a particular format (e.g. HTTP GET). You can send a representation of a new resource to the server and have the server create the resource (e.g. HTTP PUT/POST).

For example, when you upload a picture to Flickr, you are giving the server a new representation of an existing resource (e.g. through HTTP PUT/POST), and have the server modify the resource to bring it in line with the new representation.

A REST resource may be represented in many formats like XML, JSON etc.

Client and server can set the right headers in an HTTP request/response to tell the other party of the content type (or MIME type) sent or expected. This is also called content negotiation.

Resource based URI and addressability

In REST, every resource in your application has an identifiable URI (resource based URI).

Using a unique URI to identify each of your resources (or services), makes each of your resources linkable.

An identifiable URI for every resource is basis for the addressability property in resource oriented architecture.

Links and Connectedness

In the most RESTful services, representations are hypermedia: documents that contain not just data, but links to other resources.

REST web services usually follows the HATEOS principle.

‘Hypermedia As The Engine Of Application State (HATEOS)’, is a principle where your data formats drive the state transitions in your application. Links to other resources are embedded within the response and may be different every time for the same resource based on its current state.

HATEOS acts as an engine: with each response returned from a server it tells you what new interactions you can do next and where to go to transition the state.

Statelessness

REST should use stateless connections, so that no client session data is stored on the server.

If there is need for client specific data, it needs to be held and maintained by the client and send to server with each request.

REST is primarily used over HTTP and HTTP is also a stateless protocol.

The Uniform Interface

You should use a small set of well-defined methods to manipulate your resources. This make it easier to scale.

HTTP provides four basic methods for the four most common operations: GET, POST, PUT, DELETE and two less common operations: HEAD and OPTIONS. For instance, to get information about a resource you can use GET and to delete that resource you can use DELETE method.

Using HTTP methods to specify the operation will avoid the need for a separate action parameter in the URI to tell the server what action to do.

Using HTTP methods also make it easier to scale as various clients already know whether to cache a response (if it is GET method) or whether to allow duplicate requests (Server or client need not worry about duplicates for idempotent requests like PUT and DELETE, but only for a non-idempotent POST request).

You can also tell the status of the request to client by sending a standard http code so that various clients already know their meaning.

Real World Example

The RESTful Amazon S3 service provides three types of resources:

• The list of your buckets (https://s3.amazonaws.com/). There’s only one resource of this type.

• A particular bucket (https://s3.amazonaws.com/{name-of-bucket}/). There can be up to 100 resources of this type.

• A particular S3 object inside a bucket (https://s3.amazonaws.com/{name-ofbucket}/{name-of-object}). There can be infinitely many resources of this type.

Every resource exposes the same interface and works the same way. To get an object’s value you send a GET request to that object’s URI. To get only the metadata for an object you send a HEAD request to the same URI. To create a bucket, you send a PUT request to a URI that incorporates the name of the bucket. To add an object to a bucket, you send PUT to a URI that incorporates the bucket name and object name. To delete a bucket or an object, you send a DELETE request to its URI.