A beginner's guide to REST APIs

Interacting with a backend server is an important process in web development and REST APIs are one of the most widely used methods of talking to a backend server. REST means Representational State Transfer and API means Application Programming Interface. Fancy names, right? So lets dive in for more details.

Lets start by understanding APIs

APIs as stated above means Application Programming Interface. These are basically programs which are written and exposed for other programs to communicate with them. Other programs can connect with these "interfaces" and data exchange can take place. It is not necessary that only frontend and backend can communicate with each other. Different backends can also communicate with each other. In fact, there can be communication between different subsystems or services of one backend also. One good example is microservices. To facilitate this communication, REST APIs are one of the best mediums.

REST is just a set of conventions for designing, exposing and consuming an API. It has some principles and methods which makes the communication a breeze.

How REST APIs work

Here's the simple process - API is made and an endpoint is exposed for clients to use this API, client sends a request to this endpoint, API starts its process and the requested data is sent by the REST API in a response. Broadly, this is the request-response cycle. Each time client sends a new request, server treats it as a brand new request and it has no idea of the client state. No client data is stored on the server during any request. Client tells server what it needs and server supplies it with that. No personal relationships! This refers to statelessness, the soul of REST APIs!

Requests and responses work on HTTP, the Hypertext Transfer Protocol. And there are multiple HTTP methods like GET, POST, PUT, PATCH, DELETE and OPTION. These methods are used to perform the CRUD (Create, Read, Update and Delete) operations. Client uses these methods to make request to the API endpoints and each method instructs the REST API about the kind of operation that it needs to perform.

1. GET method is used to query or fetch data from the API.
2. POST method is used to tell the API that some data has to be added in the database.
3. PUT and PATCH methods are used to update data.
4. DELETE is used to tell the server that some data should be deleted.
5. OPTION is a pre-flight request which is used to know whether we can perform the required request or not. This is performed automatically by the browser.

The underlying principles of REST API

1. Statelessness - As written above, server should not store any client information. All the information needed by a server should be supplied by the client in a request object which can include headers, HTTP methods type, any data from client side etc. This allows server to treat every request as an independent request so that even if client's state changes, server can still perform its operations as expected. Besides this, statelessness also helps in making a server scalable, performant and reliable.
2. Resources - Each endpoint is treated as an entry portal to one specific resource. For example, consider a scenario of an education institution. There can be multiple resources in such a scenario, like students, teachers, batches and so on. So, we can create a separate endpoint for each of these resources and expose it for clients to access. Students resource might deal with operations like creating a new student, fetching information of all students, deleting a student record and so on.
3. Layered Architecture - Generally, it is a good practice to introduce multiple layers in your backend architecture and each layer performs specific task and nothing else. Only adjacent layers can communicate with each other and there is a uniform flow of program throughout the backend architecture. This implements separation of concern, a very good practice in programming for developing maintainable applications.

Each layer has some functions defined in them and when a request hits an API endpoint, each layer helps navigate it to an appropriate method in the next layer and finally in the DAO layer, it can have access to the database. However, it is not all necessary to make such a layered architecture in small applications. But as our application grows, such an architecture really helps, especially in maintaining the server.

Even after reviewing this post a couple of times, I feel like its not upto the mark 😅 Maybe because I am not adding any code examples in it. I'll update it in future. So, yeah, that's all for now. Hope you got some insights through this post. I genuinely feel like I have to work more on my writing style. But thanks for reading anyways!