REST Architecture

In this tutorial I will tell you about REST architecture, The most popular architectural Style for creating web services.

REST is stands for "Representational State Transfer" is not a technology that we can buy or a library that we can use in our project.

The ideas and term we use to describe "RESTful" systems were introduced and collated in Dr. Roy Fielding's thesis, "Architectural Styles and the design of Network-based Software Architecture". This Document is academic and uses formal language, but remains accessible and provide the basis for the practice.

The response of Rest full service of any kind like XML, JSON, text, or any other format.

REST vs SOAP 

SOAP web services define a protocol, a service is call SOAP only if all the specification define by protocol is followed by the service.

Unlike  REST SOAP response can be only XML format.

SOAP defines standards to be strictly followed.

SOAP requires more bandwidth and resource than REST.

Basic design principles followed by rest

1. Use HTTP method explicitly
2. Be stateless
3. Expose Directory structure-like URIs
4. Transfer XML, JSON or both.

Use HTTP method explicitly

This is one of the key characteristic of RESTful service, a way that follows the protocol as defined by RFC 2616. Below we are defining some HTTP method define in the RFC 2616.

If you want to more on detail you can follow the RFC document.

There are four main HTTP verbs or methods used by well designed RESTful systems.

The basic REST design principle establishes a one-to-one mapping between create, read, update and delete (CRUD) operations and HTTP method

1. GET (read)
2. POST (create)
3. PUT (update)
4. DELETE (delete)

GET 

In REST  style GET HTTP request is used for transferring  the representation of named resources from a server to a client.

The main key point in REST is that the GET should only used for accessing the resource from server, it should not modify anything on the server side.

GET is called a safe request because it does not changes the state of the server. The safety of a get request allow it to be cached.

GET request is also intended to be  idempotent. This means that issuing a request more than once will have no consequence.

POST

The POST request should be used when the client cannot predict the identity of the resource it is to be created.

suppose we are registering a user, in this case we have no idea how the server will name these resources.

After the successful POST request the server will return a 201 HTTP response code with a Location header indicating the location of newly created resource.

POST is neither safe and nor idempotent.

PUT

The  PUT request is used for updating an existing resource in server.

PUT is safe and idempotent.

DELETE

The DELETE request is used for removing a resource form server

There are other verbs that are not widely use but provide value.

HEAD

The head request is used to issue a request for a resource without actually retrieving it. It is a way for a client to check for the existence of a resource.

OPTIONS

The OPTIONS verb is used for interrogate a server about a resource by asking what other verbs are applicable to the resources.

Statelessness

Each of a client’s requests contains all application states necessary to understand that re-quest. None of this information is kept on the server, and none of it is implied by previous requests.

Every request is handled in isolation and evaluated against the current resource state.

URL Structure for REST web services

The URL of REST web services should be Resource based URI.

everything in the server in which user is interested should be represented as 

Resource.

For example in facebook messenger, POST, Messages, Profile and Comments are all resources

1. Noun not Verb : Use Noun in place of Verb in URI.

Example http://api.com/messages/1      [Right] 

               http://api.com/getmessages/1  [Wrong]

2. Plural not Singular : Resource name must plural not singular.

Example http://api.com/messages/1 [Right]

                 http://api.com/message/1  [Wrong}

Resource relations

one resource can depend on other resources

CASE : one to many relation

Example message and comments,  each message have multiple comments

for example message1 have comment1 with id 1, comment2 with id 2
                  message2 have comment1 with id 1, comment2 with id2

then how to make URI that represents the relation between message and comments

Here the URI syntax

http://api.com/messages/{messageId}/comments/{commentId} 

Example http://api.com/messages/1/comments/2  # message1 with comment2
                http://api.com/messages/2/comments/1  # message2 with comment1



Important HTTP codes for Rest web services