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}
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
No comments:
Post a Comment