What is R.E.S.T? Why R.E.S.T? What is RESTful API?
Today, I just thought to write about R.E.S.T architecture. First, I will explain what is meant by R.E.S.T, a story behind its creation and why most of the developers have adopted that architecture and what is RESTful API?
What and Why R.E.S.T and story behind its creation
R.E.S.T stands for Representational State Transfer(most of you know it obviously) and its a architecture style for API’s development. Basically, the story started back in December 1990 when Tim Berners Lee decided to start World Wide Web to share the information with the other limited people for research purposes. But with the advent of internet, World Wide Web project went public and in just 5years the traffic was raised to 40million people, and there was need to develop a proper architecture which should be flexible, high performant, efficient and scalable.
Therefore, R.E.S.T idea was proposed by Roy Fielding in 1995 and he proposed a set of constraints/rules that should be adopted to develop efficient and scalable systems. REST is not a specification, and they are just set of rules. The constraints are:
- Client Server
- Cache
- Statelessness
- Uniform Interface
- Layered system
- Code on demand(optional)
Note: I will discuss these constraints in detail shortly and one thing that I want to discuss first that the HTTP is not developed for R.E.S.T and HTTP was there before R.E.S.T. R.E.S.T is protocol agnostic and hence can be developed with any protocol by adhering to these constraints. Since HTTP already fulfils the R.E.S.T constraints so HTTP has become an obvious choice for the developers that go for R.E.S.T.
Client Server: This constraint says that the request is initiated by the client using standard HTTP methods to server for communication. Since client and server are decoupled from each other and hence can evolve independently without affecting each other.
Cache: This rules states that the client can cache the response for similar requests and hence avoids high network latency issues and saves bandwidth and meanwhile server can serve other requests. But the problem comes for stale data. The solution is to use Last-Modified, If-Modified-Since and Expires headers so client can always have latest data.
Statelessness: Server will not store any data related to previous requests and hence it will boost server performance in a way. By default, HTTP is stateless in nature, hence making it more suitable choice for R.E.S.T. Also the visibility of request is improved because the server does not have to look for extra information and request contain all the necessary information to query data from data-store and hence monitoring service can easily log the request for debugging and analytics purposes.
Uniform Interface: Since in real world, there can be different components that will communicate with each other or with the server and there should be a standard way of communication. Protocol provides us with a standard way of communication and hence HTTP has some methods that follows a standard way for sending request(s) and response(s). For example, HTTP GET request will have method name, URI, HTTP version, host.
GET /products.html?param1=value1¶m2=value2 HTTP/1.1
Host: www.example.comLayered system: This constraint allows developers to deploy different services on different servers. For example, gateway can be on server1, authentication service can be on server2, db server can be on server3. This decoupling allows any service to be changed without effecting any other service heavily. Since with HTTP request the client doesn’t know that in how many layers the request travels before reaching the destination.
Code on demand: This constraint is optional and allows the code scripts to be downloaded on client and hence free the server for any processing. e.g. plugins, code scripts etc. But the drawback is that the monitoring service does not have any control over it and any malicious code can harm the client.
Note: It’s not important that we should adhere to every constraint. A developer/architect can decide which constraint is more closely related to the requirement. For example, for small applications, the db server and the hosted API can be on the same machine. Code on demand conflicts with statelessness constraint as monitoring of request is not possible because server has sent the code instead of processing it by itself.
What is RESTful API?
A web API that follows the REST constraints/rules is called RESTful API.
Summary
Its important to note that the REST architecture style is not best fit for every use case and it has its own limitation like over fetching and under fetching. It has some performance issues too because with every request the data is converted into machine readable form to make it able to process by the server. Therefore, graphQL has come to cover the issue of over fetching and under fetching. gRPC, Apache Thrift, Apache Avro has come in the market to overcome the conversion issues and mostly used in microservice to microservice communication. References are attached for more clear understanding.
References
