What are Restful Web services
In this tutorial we are going to learn about Restful Web services in detail.
REST stands for Representational State Transfer.
The definitions for REST can be Vague. So, lets understand the important concepts and key abstraction in REST is a RESOURCE.
There is no restriction on what can be a resource. A to-do is a resource. A person on Facebook is a resource.
A resource has an URI i.e. Uniform Resource Identifier.
Rest doesn’t define a standard message exchange format. It can build REST services with both XML and JSON where JSON is a more popular format with REST and few SOAP services can actually be Restful.
“REST is a style of software architecture for distributed hypermedia systems.”
REST builds on top of HTTP and HTTP is the language of the web and below are the few important verbs.
POST - Create a new resource
GET - Read a resource
PUT - Update/Replace a resource
PATCH – Update/Modify a resource
DELETE – Delete a resource
HTTP also defines standard response codes among them below mentioned are the important and most used in Restful web services.
200 – 200 (OK)
201 – 201 (Created)
204 – 204 (No Content)
400 – 400 (Bad Request)
401 – 401 (Unauthorized)
404 – 404 (Not Found)
405 – 405 (Method Not Allowed)
409 – 409 (Conflict)
415 – 415 (Unsupported Media Type)
500 – 500 (Internal Server Error)
Restful web service Constraints:
Client – Server: There should be a service producer and a service consumer.
The interface (URL) is uniform in exposing resources and interface used nouns but not verbs. The service is stateless i.e. even if a service is called n times, the result must be same. Statelessness means that every HTTP request happens in complete isolation.
When the client makes an HTTP request, it includes all information necessary for the server to fulfil that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request.
For becoming stateless, do not store even authentication/authorization details of client.
Provide credentials with the request. Each request MUST stand alone and should not be affected by the previous conversation happened from the same client in past.
Being cacheable is one of architectural constraints of REST. GET requests should be cacheable by default – until special condition arises. Usually, browsers treat all GET requests cacheable.
POST requests are not cacheable by default but can be made cacheable if either an Expires header or a Cache-Control header with a directive, to explicitly allows caching, is added to the response. Responses to PUT and DELETE requests are not cacheable at all.
