REST APIs

Hey everyone!

In this blog, we’ll explore what REST APIs are. This post is part of the System Design for Beginners Series.

If you’re completely new to this, my suggestion is not to overwhelm yourself with too much information. Understand what you can and move ahead ( let the future you suffer 😉 )

API

API stands for Application Programming Interface.

APIs are protocols (a set of rules) for building and integrating apps.

APIs allow communication between client and server. As a college student or fresher, you usually create APIs in the backend using Node, Python, etc. and then try to fetch some data or perform some function based on user activity on the frontend.

Let’s say you created a website where your whole business logic is on a Node.js backend.

When a user clicks on the profile page, you want to get their profile image from the backend.

So the client hit an API to get the profile image of the user.

Now the user wants to update the profile image by uploading a new profile image.

So the client hits an API to store the new profile image.

We use APIs to perform some actions on the server. It can be to get data, store data, or perform some function.

So if you are a frontend developer, you will use the APIs provided by the backend team. e.g., hit the POST API for storing information when the user clicks on the submit button.

If you are a backend developer, your job is to create APIs and provide them to the frontend team.

HTTP APIs

HTTP stands for HyperText Transfer Protocol. It is set of communication protocols.

Suppose I ask you to read this: “ich bin ein Idiot” . If you don’t understand German, then for you, this is just some random letters.

Now what if your client is sending data in some form, like JSON, but the server is developed in Python (assuming that it does not understand JSON), You won’t be able to work with that data.

So for client and the server to communicate, there should be some rules defined, like how data will be shared, in what form data is to be converted ?, etc.

HTTP is set of rules that defines how your client and server will communicate with each other.

REST APIs

REST stands for REpresentational State Transfer

REST is a set of rules. So if you follow these rules while creating your APIs, you can say you have developed REST APIs.

So, what are the rules ?

• Client-Server Architecture : The application should be divided into 2 components, i.e client and server.
• Stateless : The server should not store any information (state) regarding APIs like HTTP methods, data, etc.
• Cacheable: The server, when sending a response, specifies whether the response is cacheable or not. It also specifies on what conditions it should be cacheable. ( e.g don’t cache sensitive data )
• Uniform interface : It means that there should be uniformity when creating APIs, each resource should be identified with it’s own URI, and APIs should use HTTP methods (GET, POST, PUT, DELETE), etc.
• Layered System : Components cannot see beyond certain layer. if client makes API request to server. API will only be interacting with server, client should not be able to see beyond server, like Database, caches, etc.

That’s all for today, folks. Catch up with this series later for more updates on System Design Basics from your host and dost — Bhavesh

If you found this helpful, feel free to like it and share your thoughts in the comments! ✨

Next up, we’ll dive into Message Queues.