この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Introduction
These days, while reading through the documentation of an API, I saw that it is RESTful. I have come across this term in the past as well, even though I have a brief overview of h
REST stands for REpresentational State Transfer, it is an architectural style designed for web based applications and has found new heights of application in this age of adaptation to microservices architecture.
If you are not familiar with microservice architecture then you can know about it from here.
REST makes it easier for clients and servers to communicate with each other by providing well defined roles for both of them, they are both stateless.
REST works follows some concepts in its design, it is very important for us to understand that in no way does REST define a specific API, it is defined an architecture on the basis of which APIs can be implemented, and these APIs are called RESTful. So the next time you see that being mentioned, you'll know what it really stands for. Now, let's look into what is it that REST architecture defines for users to follow.
Separation of client and server
The code on the client side can be changed without any changes on the server side, and vice versa, the other party need not even know that the code is being modified/changes as long as the format of the messages being exchanged remain the same, this allows the system to have additional modularity.
Statelessness
Statelessness means the client is not aware of the server and vice versa, in this way, no new message requires the client/server to see the previous message, because all messages are independent of each other. This is implemented through usage of resources instead of enforcing commands.
Resources are nouns of the web, they can describe any object, document or thing.
Communication between Client and Server
In REST, clients send requests to retrieve or modify resources and servers send responses.
Making Requests
A client makes a request to perform an operation which is generally to modify data or delete data which is present on the server. A client request generally consists of the following things :
- HTTP method name
- A header which defines the action to be performed
- URI of the resource
- Message body for extra information
Accept Field
The accept field is a field in the client request header which specifies the format in which the client expects data to be returned from the server so that it does not receive something it cannot understand.
MIME types are used to perform this operation, they consist of a type and sub type.
So if the client expects a screenshot as the return value to the request then the accept field is image/png . Where image is the type and png is the sub type.
If there are more than a single type, then they are all separated by commas.
Paths
As mentioned, the request body contains the location of the resource as well, this URI also has some certain conventions, the first part of the URI must be a name of the resource in itself, after this every resource can be accessed through their URI , under every category the resources can be accessed through their unique ID.
Responses
While sending data from the server to the client, the header must contain a small field called ‘content-type’ which lets the client know whether it is compatible or not. content-type header can include any format as long as it is supported by the service to which the API call is being made to.
Server responses are also generally in terms of HTTP status codes.
The content-type specified in the header of the response must also be present in the accept field of the client. Every operation has a different HTTP code associated with its success.
All of the data exchange which takes place takes place in JSON/xml file format.
Conclusion
I hope reading this blog has helped you in understanding all the basics of REST architecture. This also highlights why REST is so popular among users. However if you want a deeper insight into REST then you can read about Guiding principles of REST and learn more about it.