Thread by @Rapid_API

Learn REST APIs

In this thread, we will talk about HTTP methods, principles of REST APIs, security, and versioning.

🧵👇🏻

The abbreviation REST stands for "REpresentational State Transfer".

REST APIs operate on a simple request/response system. You can send a request using these HTTP methods:

HTTP has a fixed number of methods that the client can use to indicate what type of operation it wants to perform via the request.

🔹 GET
🔹 POST
🔹 PUT
🔹 PATCH
🔹 DELETE
🔹 HEAD
🔹 TRACE
🔹 OPTIONS
🔹 CONNECT

If an HTTP method doesn’t alter the server's state apart from logging, it is called a safe method.

GET, HEAD, or OPTIONS methods are safe methods.

It is important to note that all the safe HTTP methods are also idempotent, but not all idempotent HTTP methods are safe.

When multiple calls of an HTTP method yield the same result and leave the server in the same state, then the HTTP method is called idempotent.

When implemented correctly, the GET, HEAD, PUT, and DELETE methods are all idempotent, but not the POST method.

It's possible to cache the response and use it later.

◾ GET, and HEAD methods are cacheable.
◾ POST and PATCH methods are also cacheable if the Content-Location header is set.
◾ The 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 status codes are cacheable.

📌 REST APIs follows six design principles which are as follows: 👇🏻

1️⃣ Client-server Separation

In a RESTful API, the client and server are always kept independent, ensuring that both the client and the server can be scaled independently.

2️⃣ Stateless

Servers aren’t allowed to store any data related to the client. No session or authentication state is stored on the server.

If the client requires authentication, then the client needs to authenticate itself before sending a request to the server.

3️⃣ Cacheable

Responses can be explicitly or implicitly defined as cacheable or non-cacheable to improve scalability and performance.

The main idea of caching is to improve the performance of the client by reducing the bandwidth required to load the resource.

4️⃣ Layered System

It isn’t always necessarily true that the client connects directly to the server and requests a resource. There can be multiple systems in between them that are responsible for handling security, traffic, balancing the load, redirection, etc.

5️⃣ Uniform Interface

The client and server can interact with each other in a single language irrespective of the architecture that they are based upon.

6️⃣ Code on Demand (optional)

When a client requests a resource, the server can return executables as a part of the response. This is an optional constraint.

In some instances, this might help reduce the amount of code that has to be written on the client.

📌 Security

We can use Content Security Policy (CSP) to provide an extra layer of security over various issues like XSS and data injection.

Using CSP, it is possible to limit the amount of data sources that a web application can load. This is done by properly configuring the CSP headers.

CSP can prevent errors that occur due to unsigned inline JavaScript and CSS style tags as well as JavaScript code using eval().

📌 Versioning

There are three different types of versioning strategies: 👇🏻

1️⃣ URI versioning

This is the most common versioning strategy, although it violates every URI should contain a unique resource. When a URI version is done, all the resources get updated to a new version.

2️⃣ Query parameters versioning

This strategy states the version of an API by using query parameters. An example of this kind of strategy can be the following: 👇🏻

3️⃣ Custom headers versioning

Versioning can also be done by passing custom request headers. An example will be the following:

Visit RapidAPI Learn (RapidAPI.com/learn/rest-api…) to play around with interactive components and build a strong understanding of REST APIs.

With that being said, this is the end of this thread.

We recommend you head over to RapidAPI Hub (RapidAPI.com/hub?utm_source…) to access more than 35,000 APIs. 💙😉