REST

REST - REpresentational State Transfer

Popular, easy to implement, and use HTTP methods.

GET

POST

PUT

Most of the web services (example: Youtube, Twitter), that we use daily are powered by REST API.

Public REST APIsPublic REST APIs

1. Statelessness: Each request from the client to the server must contain all the necessary information to understand and process the request. The server does not maintain any client state between requests.

2. Uniform Interface: REST APIs use a uniform set of well-defined methods and conventions for interacting with resources. The commonly used HTTP methods are GET, POST, PUT, and DELETE, corresponding to retrieving, creating, updating, and deleting resources.

3. Resource-Based: Resources are the fundamental units in a REST API. Each resource is identified by a unique URL (Uniform Resource Locator), and clients interact with these resources through the API endpoints.

4. Representation: Resources are in a specific format, such as JSON (JavaScript Object Notation) or XML (eXtensible Markup Language). Clients and servers use these representations to exchange data.

5. State Transfer: The server transfers the state of a resource to the client through representations. Clients can modify the state of a resource by sending requests to the server.

When not to use

1. Real-time applications: If you're building a real-time application that requires bi-directional communication, such as chat applications or real-time collaboration tools, REST may not be the most efficient option. Using technologies like WebSockets or server-side push technologies might be more appropriate in such cases.

2. Complex operations: If your application requires complex operations that do not fit well into the standard CRUD (Create, Read, Update, Delete) model, REST may not be the most suitable choice. REST is ideal for simple operations on resources.

3. Fine-grained control over data: If your application requires fine-grained control over the data being exchanged, including data validation, authorization, and access control, REST may not provide the level of control you need. In such cases, a more customized and fine-tuned approach may be required.

4. Performance-critical applications: If your application requires extremely high performance and low latency, REST may introduce additional overhead due to its statelessness and the need to transfer representations with each request. In such cases, more optimized protocols or communication mechanisms may be preferred.

5. Legacy systems and protocols: If you're working with legacy systems or protocols that do not adhere to the principles of REST, it may not be feasible or practical to implement a REST API. In such cases, you may need to work with the existing technology stack or consider alternative integration approaches.