Principles of Rest API
1. Client-Server decoupling
In a REST API design, client and server programs must be independent. The client software should only know the URI of the requested resource; it should have no additional interaction with the server application.
2. Uniform Interface
All API queries for the same resource should look the same regardless of where they come from. The REST API should ensure that similar data, such as a user's name or email address, is assigned to just one uniform resource identifier (URI).
3. Statelessness
REST APIs are stateless, meaning each request must contain all the information needed to process it.
4. Layered System architecture
REST API requests and responses are routed through many tiers. REST APIs must be designed so neither the client nor the server can tell whether they communicate with the final application or an intermediary.
5. Cacheable
Wherever feasible, resources should be cacheable on the client or server side. Server responses must additionally indicate if caching is authorized for the offered assistance. The objective is to boost client-side speed while enhancing server-side scalability.
6. Code on Demand
REST APIs typically provide static resources, but in rare cases, responses may include executable code (such as Java applets). In these cases, perform the code when necessary.
___________________________________________________________________________________
Methods of Rest API
1. GET
The most popular HTTP method, GET, returns a representative view of the information and data contained in a resource. For data security and resource idempotence, the Use of GET should only be in read-only mode. If another client hasn't changed this technique in the interim, you should always obtain the same results regardless of how many times you use it.
2. POST
POST is the sole HTTP method for RESTful APIs that focuses on resource collections. Applying POST to the parent resource causes it to build a new resource, add it to the correct hierarchy, and return a specific URL for future use for establishing a subordinate resource in a collection. However, remember that POST is not idempotent; you cannot repeatedly employ this technique and anticipate a consistent result.
3. PUT
The PUT command modifies a resource by completely replacing its content, making it the single-resource counterpart of POST. As a result, PUT is the most popular technique for updating resource data in a RESTful API.
4. PATCH
Another HTTP method for updating resources is PATCH. PATCH alters resource contents instead of replacing resources, like the PUT method. These updates should often be conveyed using a common format, such as JSON or XML.
5. DELETE
DELETE is the final HTTP method to look at. Targeting a single resource with a DELETE method results in the complete deletion of that resource.
