REST stands for REpresentational State Transfer. This concept was given by a guy named Roy Fielding.
REST is an architecture style for designing networked applications. The basic idea behind it is, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.
It relies on a stateless, client-server, cache-able communications protocol, the HTTP protocol is used.
REST make use of HTTP, which stands for HyperText Transfer Protocol.
The REST api uses resource based URIs to make calls between machines
We may have different kind of URIs, action based or resource based.
For example.
myweatherapp.com/weatherLookup.do?zipcode=453441
This is a action based URI which is saying that take zipcode as an argument and do something. So it is typically considering server side implementation.
On the other hand,
myweatherapp.com/zipcode/453441
This is resource based URI, which is looks like it is saying that look for something which is already there rather than doing some processing.
SOAP is another way of making calls to different machines. SOAP have well defined guidelines to use, if any of them gets violated than the request becomes no more a SOAP request.
SOAP has wsdl, i.e. the service definition. For example if we have a predefined class and we want to use its one of the method, than we should be aware of what all methods are available, what is the return type, what are the arguments does it takes. So all, these details are known as service definition. So for web services, if we use SOAP than these rules are written in a document named WSDL.
What about REST? Well, the answer is, it doesn't uses any service definition.
Http being a stateless protocol doesn't retains the any information or status of each request made by the user. Each request is treated as independent.
Idempotent means user can make many request without affecting the result. This means that if the same request is sent again and again it will not change the result. For example http://flipkart.com/useranonymous/order/45 will result in the same data even if this request is fired many times.
Get is used to request data from the server
Put is used to update a resource
Post is used to create a resource
put is repeatable because if we try to update a resource by repeating the same action multiple times. It won't change the the resource.
post is not repeatable because every duplicate call will create a new thing with the same content.
Creating resource using GET
It is possible to create a resource using GET method but that is not a good practice because it may confuse the client(browser) for creating safeguards. For example if a user submits the a GET request and if he clicks on refresh button, the request is submitted again directly and receives the response.
What if, after submitting a form the user clicks on refresh button. The browser warns the user whether they want to resubmit the form. This is one of the safeguard by the client.
REST is an architecture style for designing networked applications. The basic idea behind it is, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.
It relies on a stateless, client-server, cache-able communications protocol, the HTTP protocol is used.
REST make use of HTTP, which stands for HyperText Transfer Protocol.
The REST api uses resource based URIs to make calls between machines
We may have different kind of URIs, action based or resource based.
For example.
myweatherapp.com/weatherLookup.do?zipcode=453441
This is a action based URI which is saying that take zipcode as an argument and do something. So it is typically considering server side implementation.
On the other hand,
myweatherapp.com/zipcode/453441
This is resource based URI, which is looks like it is saying that look for something which is already there rather than doing some processing.
SOAP is another way of making calls to different machines. SOAP have well defined guidelines to use, if any of them gets violated than the request becomes no more a SOAP request.
SOAP has wsdl, i.e. the service definition. For example if we have a predefined class and we want to use its one of the method, than we should be aware of what all methods are available, what is the return type, what are the arguments does it takes. So all, these details are known as service definition. So for web services, if we use SOAP than these rules are written in a document named WSDL.
What about REST? Well, the answer is, it doesn't uses any service definition.
Http being a stateless protocol doesn't retains the any information or status of each request made by the user. Each request is treated as independent.
Idempotent means user can make many request without affecting the result. This means that if the same request is sent again and again it will not change the result. For example http://flipkart.com/useranonymous/order/45 will result in the same data even if this request is fired many times.
Get is used to request data from the server
Put is used to update a resource
Post is used to create a resource
Method | Type | safe?(repeatation-wise) | Safe?(Modification-wise) | Idempotent? | Repeatable? |
---|---|---|---|---|---|
GET | Read-only | Yes | Yes | Yes | Yes |
POST | Write | No | No | No | No |
PUT | Write | Yes | No | Yes | Yes |
DELETE | Write | Yes | No | Yes | Yes |
put is repeatable because if we try to update a resource by repeating the same action multiple times. It won't change the the resource.
post is not repeatable because every duplicate call will create a new thing with the same content.
Creating resource using GET
It is possible to create a resource using GET method but that is not a good practice because it may confuse the client(browser) for creating safeguards. For example if a user submits the a GET request and if he clicks on refresh button, the request is submitted again directly and receives the response.
What if, after submitting a form the user clicks on refresh button. The browser warns the user whether they want to resubmit the form. This is one of the safeguard by the client.
0 comments:
Post a Comment