RESTful Design Principles

Here, we will outline the set of RESTful design principles that should be adhered to when creating a ‘proper’ RESTful service.

Let’s start with the basics. What is REST?

REST = REpresentational State Transfer. REST is an architecrtural style. It relies on a stateless, client-server, cacheable communications protocol. Nowadays, many REST applications are built using the HTTP protocol, however REST is not tied to a specific protocol. HTTP and REST make for a great match. Together they help to create a simple, lightweight foundation with which we can build complex web applications. At the heart of REST with HTTP, are the HTTP methods. They can be loosely thought of as our CRUD operations e.g. Create, Read, Update, Delete. By leveraging HTTP, a REST application oftens maps POST, GET, PUT, and DELETE to the CRUD operations. For the remainder of this POST we will discuss REST with HTTP in mind.

REST terminology:

Resources:

Resources are nouns. Resources are identified by URIs
e.g. Car identified by http://www.automart.com/cars/12345

Methods:

Methods are verbs. They perform CRUD operations.
Methods are: POST, GET, PUT, DELETE

Representation:

Data or state of a resource represented in some format e.g. XML, JSON, etc

The REST Doctrine

1. Everything is a Resource!!
e.g Car, Engine, Part, etc
Every resource has an ID! An ID is a URI. A URI may identify items, collections, or computation results.

e.g.
a URI that identifies a specific car: http://www.automart.com/cars/12345
a URI that identifies a list of cars: http://www.automart.com/cars

2. All resources expose a standard interface
For example: Car, http://www.automart.com/cars/12343 may have the following methods: GET, POST, PUT, DELETE which might do the following:

GET returns the data or state the represents the resource, http://www.automart.com/cars/12343.
An XML representation of that state might be:


    <Car>
      <Make>Audi</Make>
      <Model>A5</Model>
      <Year>2013</Year>
    </Car>

POST – Creates new car. You might post a similar XML doc when creating a resource.
PUT – Updates a car. Again you might post a similar XML doc when updating a resource.

DELETE – Remove the car

3. Operation characteristics
The following characteristics may exist for REST operations:
– Safe – the operation must not have side effects
– Cacheable – the result may be cached e.g. by a proxy server
– Idempotent – The operation must always return the same result

RESTful HTTP methods have the following characteristics:
GET – Safe, Cacheable, Idempotent
PUT – Idempotent
DELETE – Idempotent
HEAD – Safe, Idempotent
POST – n/a

4. Linked Resources
Resource representations may contain links to other resources
e.g.


    <Car>
      ...
      <Engine uri="http://www.automart.com/engine/v8/1242"/>
      ...
    </Car>

5. Multiple representations
Data is represented in various formats: XML, JSON, etc\
e.g. XML


    <Car>
      <Make>Audi</Make>
      <Model>A5</Model>
      <Year>2013</Year>
    </Car>

or JSON

    "Car": {
         "Make" : "Audi",
         "Model" : "A5",
         "Year" : "2013" }

or …

5. Stateless communication
Everything that is required to process a request is required to be in the request.
There is no client session on the server!

That’s REST (using HTTP) in a nutshell!

Thank you!

You may also like...

4 Responses

  1. April 5, 2014

    […] (For a detailed explanation of REST. See my post on RESTful Design principles) […]

  2. July 2, 2014

    seo services

    RESTful Design Principles | c m d

  3. July 5, 2014

    […] design principles RESTful […]

Leave a Reply