Imagine walking into a restaurant. You don’t step into the kitchen, tell the chef how to cook, or worry about how many ovens are running. You simply look at the menu, place an order, and wait for your food to arrive.
This is very similar to how a client interacts with a REST API. The client doesn’t care how the server is implemented internally; it only cares about what it can request and what it gets back.
One of the most important things for a web developer is to understand how a RESTful API works and how it is structured. REST or Representational State Transfer (REST) is an architectural style for designing web APIs. REST defines a set of rules and constraints that govern how clients and servers communicate with each other. In practice, REST APIs are most commonly implemented on top of the HTTP protocol. We will discuss the core principles of a REST API.
1. Client Server Separation
In REST, the client (frontend, mobile app) & the server are treated as two separate entities. Each can grow independently of the other. The client does not care about how the server is implemented. It only cares about the response it receives and how that response is structured.
When a person goes to a restaurant and orders a 3-course meal, the customer does not care which items get cooked first, how many ovens the kitchen has or where the stove is located, if the kitchen is using gas or electricity to cook food. The customer cares only about his meal and how it tastes. Similarly, in REST, the client only cares about the response & it’s shape of the api request.
2. Statelessness
One of the most important characteristics of REST is that it is stateless.
We need to understand what stateless means. Being stateless means:
- The server does not remember or store client-specific states, and
- Every request is treated independently, and each request must contain all the information the server needs to process it.
- The server does not remember anything about previous requests
However, being stateless does NOT mean:
- The server does not store any data or
- Database does not have any state related to client sessions
Let us see a real-life example regarding statefulness and statelessness. Suppose you go to a restaurant for breakfast and you order the same thing every single day. If the restaurant is a big outlet and extremely busy, chances are no one will remember what you ordered the previous day. You will have to tell the waiter everything again and again. This is an example of statelessness.
But if it is a small restaurant and you see the same waiter each time you go there, chances are the waiter will know what you order regularly, and they will bring your favourite dish tailored to your liking without you needing to explicitly tell them everything. This is an example of statefulness.
In a REST API, each request is like walking into the restaurant for the first time - you must provide everything the server needs to know. Being stateless gives it high flexibility and scalability. We can easily scale it to thousands of requests. But it has its downside as well. However, statelessness also has downsides, such as increased request size and repeated authentication on every request. This puts an increased load on the server.
3. Resource-Based Design
One of the core ideas behind REST is resource-based design. In REST, everything the client interacts with is treated as a resource. A resource can be anything meaningful in your application, such as users, orders, products, or payments.
Each resource is uniquely identified by a URI (or URL). The URI acts like an address that tells the server exactly which resource the client wants to work with.
Think of a REST API like a restaurant menu.
- The menu itself does not describe how the food is cooked; it simply lists what is available.
- Each item on the menu has a clear identity.
- The menu sections (Starters, Main Course, Desserts) are like resource collections
- A specific dish (Grilled Chicken, Chocolate Cake) is like an individual resource
- The dish name is the identifier, just like a URL identifies a resource
For example:
When a customer interacts with the menu:
- They are not concerned with the kitchen logic
- They are only selecting which item they want to interact with
Similarly, in REST:
- The client interacts with resources via URLs
- The client does not need to know how the server stores or processes those resources
4. Uniform Interface
Rest API follows consistent rules. It uses clear and consistent URIs or URLs. It uses standard HTTP methods and status codes, and it also uses a consistent data format for requests and responses, which we will discuss now.
5. Representation of Resources
In the response of the REST, JSON is commonly used. Client and server exchange data in a format they agree upon.
6. Use of HTTP Methods (Verbs)
One of the most important aspects of REST is the HTTP methods or verbs. It tells the server what the client expects the server to do. REST APIs primarily use standard HTTP methods (also called verbs):
- GET
- POST
- PUT
- PATCH
- DELETE
Suppose someone is ordering a 3-course meal. When the waiter is asked to create the order, it is a POST method. When the order is prepared, the waiter will inform the customer. When the customer asks the waiter about the order or requests it to be served, it resembles a GET request. The customer may change their mind and may want to try something completely different. It’s a PUT method. The customer may want to just change what he wants for dessert. That’s a PATCH method. The customer may want to cancel the order altogether. That’s a DELETE method.
HTTP Method Table
| Method | Purpose | Analogy |
|---|---|---|
| POST | Creates New Resource | Places the 3-course meal order |
| GET | Retrieve Resource | Retrieve information about the order or ask to serve it |
| PUT | Update Entire Resource | Changes items in the order |
| PATCH | Update Partial Resource | Changes only partial items (eg. desert) of the order |
| DELETE | Removes Resource | Cancels the entire order |
7. Use of HTTP Status Codes
For beginners, HTTP status code is one of the vital things to learn. Each time a client sends a request to the server, the server provides a status code of the request in the response along with some other data. The status code gives the client an idea of the state of the request without looking into further details of the response. It tells the client if the request is successful, failed or needs further action. Status codes are grouped in five categories.
- 1xx : Informational → for request processing
- 2xx : Success → for successful requests
- 3xx : Redirection → for requests requiring redirection
- 4xx : Client Errors → for invalid request from the client
- 5xx : Server Errors → for failure on the server side
Using correct HTTP status codes improves clarity, debugging, and API reliability. Here are some most commonly used HTTP status codes and their meaning.
| Code | Meaning |
|---|---|
| 200 | Ok |
| 201 | Created |
| 400 | Bad Request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 500 | Server Error |
Top comments (0)