REST Essentials
World before REST
As you can see in the image, the client had to understand HTML (language that server speaks)and parse it. Similarly, if there were different languages i.e JSON, XML that the clients understood, the server had to cater to those clients and update the response based on that.
There was no standarised way of interacting with different systems, which is when REST came in existence.
What is REST?
REST is an architectural style that,
- Standardises communication between computer systems.
- Utilises most of the constructs of the HTTP protocol.
Key Principles
- Stateless
- Uniform Interface
- Cacheable
- Layered
Before we go ahead and understand REST constraints, let’s understand HTTP constructs, as REST is based on these constructs.
The above image shows how a typical REST GET api request would look like and explains the components of a request.
Let’s dive into each principle in detail,
- Stateless: Each request is self-descriptive and has enough context for the server to process it.
For example,
Consider an auto insurance application,
Request: User / Client submits driver and vehicle details
Response: Server responds with a quote valid for a week
Problem: User / Client wants to Purchase insurance with quote generated in response. So, quote here is the application state that needs to be shared between 2 requests. Below are possible solutions to achieve with stateless approach,
2. Uniform Interface: A standardised method for clients to interact with the server, irrespective of the device or application.
To achieve a uniform interface, we use HTTP constructs:
- Resource Identifiers
- Manipulation of Resources → HTTP Methods (eg. GET, PUT etc)
- Resource Representations eg.JSON, XML etc
- Self-Descriptive Messages eg.media type, cache control
Let’s take a look at the first 2 points a little more in detail,
Resource Identification
Whenever you are identifying resources, there are a few factors that need to be considered.
- Domain modelling
- Hierarchy
- Design of database tables and object models
- Resource Granularity
Using the right HTTP method
GET: Fetch a resource
PUT: Update a resource
POST: Create a resource
DELETE: Delete a resource
While using any of the HTTP methods, we have to make sure that the methods are safe and idempotent, as shown below,
3. Layered: Components are organised into layers, where each layer has a specific set of responsibilities and interacts with adjacent layers in well-defined ways.
As you can see in the image most commonly we layer the system as above.
4. Cacheable: The cacheability of a resource is defined by the Cache-Control header in the HTTP response.
The Cache-Control header includes directives that specify caching behaviour as follows:
- public: Indicates that the response can be cached by any cache (including intermediary proxies).
- private: The response is intended for a single user and should not be cached by intermediary proxies.
- no-cache and no-store: The response shouldn’t be stored or cached.
- max-age: Specifies the maximum amount of time (in seconds) a response can be considered fresh.
Conclusion
We’ve explored the fundamentals of REST architecture, by adhering to it, we can design
- Scalable APIs
- Maintainable APIs
- Interoperable APIs
