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.
There are different kinds of specifications available that you can use while building an API.
In this thread, we will talk about the OpenAPI spec.
𧡠ππ»
In simple terms, OpenAPI spec is a format to define structure and syntax for REST APIs.
OpenAPI spec provides a standard that allows both humans and computers to discover and understand the service's capabilities without access to source code, documentation, or traffic inspection