Web Services (What are REST Web Services)-Part(4)
In this tutorial, we are going to learn about REST and RESTfull web services. We will go very basic step by step and we will learn how can we call a web service as a RESTfull Web Service.
So REST is a very important but often misunderstood concept in WEB Services. So let us decode REST today. In the earlier tutorials, we have seen that Web Services can be implemented in 2 major ways.
- SOAP (Simple Object Access Protocol)
- REST (Representational State Transfer)
We already know that web services allow communication between 2 applications (Service Provider and Service Consumer). So let's see how REST fits into this architecture.
We can say that REST is a web service that communicates / exchange information between 2 applications using REST architecture/principles is called a RESTful Web Service.
Let us break this definition in a simple way.
What is REST?
REST is an architectural style. Unlike SOAP, REST is not a protocol. There are no strict specification and central body which is controlling these specifications. So REST is a design principle and you can use this to create any service. Then when you applying these principles while creating a web service we get RESTful Web Service.
What are the principles/constraints of REST architecture?
These are some of the principles or constraints of the REST. What rules should a web service follow to become a RESTful Web Service?
UNIFORM INTERFACE — (Principle 1)
We can divide the first principle into several parts.
1. Everything is a Resource
Let’s take an example Employment Management System. I can create this application using any language on any platform and using any Database. I will have some modules and entities on my application.
Here we are explaining in the REST concept of Resources says you can define ani information or module as a resource. If you want any resource to your application you can add employees departments and like this, we can add any resource to any module. REST does not say what exactly needs to use as a resource. You can define any information, any module or any data as a resource.
2. Any resource/data can be accessed by a URI (Uniform Resource Identifier)
For Example, if I hosted the previous application I can use that domain name using,
https://www.example.com/employees
If I want to go a little deeper and access the details of a particular employee. I can use this one.
https://www.example.com/employees/{employeeId}
And I can use tables in the Database to get data.
Now how to get a list of employees from a particular department? I can use this.
https://www.example.com/123/employees
So this is how we can make use of resources and URI in REST.
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
Roy Fielding
3. Make explicit use of HTTP methods
We know HTTP has some methods like POST(Create), GET (Read ), PUT(Update), DELETE(Delete), headers option and so on.
Using HTTP Methods along with URI, we can access/modify any resource or resource information.
It is a good practice in REST that whenever you name your resources you need to use proper NAMES and HTTP actions we can consider as VERBS.
Please use a specific format for rest calls.
Do not use this type of REST requests,
Use this type,
4. Manipulation of Resources using Representations Responses
Each resource can have one or more representations. Such as application/xml, application/json, text/html etc. Clients and servers negotiate to select the representation.
5. Self-descriptive messages
REST Requests and Responses contain not only data but headers describing how-to content should be handled. Such as if it should be cached, authentication, requirements, etc.
We will discuss other principles in another tutorial. Thank You!
