REST is not a protocol or a standard, but rather a set of architectural constraints. REST can be implemented in a variety of ways by API developers.
A RESTful API sends a representation of the resource’s state to the requester or endpoint when a client request is made. JSON (Java script Object Notation), HTML, XLT, Python, PHP, or plain text are among the formats delivered via HTTP. JSON is the most widely used file format because, contrary to its name, it is language-independent and readable by both humans and machines.
Another thing to remember is that the HTTP methods of a RESTful API HTTP request contain important identifier information such as the request’s metadata, authorization, uniform resource identifier (URI), caching, cookies, and more. There are two types of headers: request headers and response headers, each with its own set of HTTP connection information and status codes.
To be considered RESTful, an API must meet the following requirements:
Clients, servers, and resources make up a client-server architecture, with HTTP requests managing requests.
Client-server communication that is stateless means that no clientinformation is stored between get requests and that each request is distinct and unrelated.
Data that can be cached to improve client-server interactions.
A uniform interface between components so that information is transferred in a standard form. This requires that:
The requested resources are distinct from the representations sent to the client.
The client can manipulate resources using the representation they receive because the representation contains sufficient information.
The information in self-descriptive messages returned to the client is sufficient to describe how the client should process them.
If hypertext/hypermedia is available, the client should be able to use hyperlinks to find all other currently available actions after accessing a resource.
The retrieval of requested information into hierarchies, which are invisible to the client, is part of a layered system that organizes each type of server (those responsible for security, load-balancing, and so on).
Code-on-demand (optional): the ability to send executable code from the server to the client when it is requested, thereby increasing client functionality.
The HTTP verbs make up a large part of our “uniform interface” constraint, as they are the action counterpart to the noun-based resource. POST, GET, PUT, PATCH, and DELETE are the most commonly used HTTP verbs (or methods, as they are officially known). These represent the operations of create, read, update, and delete (or CRUD). There are a few other verbs as well, but they are used less frequently. OPTIONS and HEAD are used more frequently than the other less-frequent methods.
REST defines six architectural constraints that define a truly RESTful API in any web service.
6.Code on demand
As the constraint name implies, you MUST choose an API interface for internal system resources that are exposed to API consumers and stick to it. A system resource should have only one logical URI that can be used to retrieve related or additional data. It is always preferable to replace a resource with a web page.
Any single resource should not be excessively large and should not represent everything. A resource should contain links (HATEOAS) pointing to relative URIs to fetch related information whenever possible.
This constraint essentially states that client and server applications must be able to evolve independently of one another. Only resource URIs should be known by the client. This is now standard practice in web development, so you won’t have to do anything special. Keep it straightforward.
HTTP inspired Roy Fielding, which is reflected in this constraint. Every client-server interaction should be stateless. The server will not keep track of the client’s most recent HTTP request. Every request will be treated as fresh. There is no session and no history.
If the client application is required to be a stateful application for the end-user, where the user logs in once and then performs other authorized operations, then each client request should include all of the information required to service the request, including authentication and authorization details.
Data and response caching is critical in today’s world, wherever they are applicable or possible. This page is also a cached version of the HTML page you’re reading. Because the load on the server is reduced, caching improves client performance and gives the server more scalability options.
When possible, caching should be applied to resources in REST, and these resources MUST declare themselves cacheable. Caching can be done on the server or on the client.
REST enables you to use a layered system architecture, such as deploying APIs on server A, storing data on server B, and authenticating requests on server C. Normally, a client cannot tell whether it is connected directly to the end server or through an intermediary.
Code on demand
This constraint, however, is optional. The static representations of resources will be sent most of the time in the form of XML or JSON. However, you are free to return executable code to support a part of your application when necessary, such as when clients call your API for UI widget rendering code. It is permissible.
REST API DESIGN BEST PRACTICES
1.JSON must be accepted and returned by one rest api.
2. Make use of error status codes.
3. Avoid using verbs in URLs.
4. When naming a collection, use plural nouns.
5. Documentation that is well-organized
6. Include details about the error in the response body.
7. Implement resource nesting
7. Implement resource nesting
9. Keep your API safe.