Understanding REST: REpresentational State Transfer
Tags: webdev, beginners, programming, tutorial
Published: 2024-01-17 10:16:05

**<u>REpresentational State Transfer</u>**
REST, or REpresentational State Transfer, is an architectural style that standardizes the communication between computer systems on the web, making it easier for them to interact seamlessly. 

Systems that adhere to REST principles, known as RESTful systems, are characterized by their statelessness and the separation of client and server concerns. 

Let's delve into these terms and explore why they are beneficial for web services. 

**Separation of Client and Server**
In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other. 

This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.

As long as each side knows what format of messages to send to the other, they can be kept modular and separate. 

Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. 

Additionally, the separation allows each component the ability to evolve independently.

With a REST interface, different clients can interact with the same REST endpoints, perform the same actions, and receive consistent responses. 

**Statelessness**
Systems that follow the REST paradigm are stateless, meaning that the server does not need to know anything about what state the client is in and vice versa. 

In this way, both the server and the client can understand any message received, even without seeing previous messages. This constraint of statelessness is enforced through the use of resources, rather than commands. Resources are the nouns of the Web - they describe any object, document, or thing that you may need to store or send to other services.

Because REST systems interact through standard operations on resources, they do not rely on the implementation of interfaces.

These constraints help RESTful applications achieve reliability, quick performance, and scalability, as components that can be managed, updated, and reused without affecting the system as a whole, even during operation of the system.

Now, we’ll explore how the communication between the client and server actually happens when we are implementing a RESTful interface.

**Client-Server Communication**

In the REST architecture, clients send requests to retrieve or modify resources, and servers send responses to these requests. 
Let’s take a look at the standard ways to make requests and send responses.

**Making Requests**
A typical REST request includes:

- An HTTP verb: Specifies the type of operation.
- A header: Passes additional information about the request.
- A path to a resource: Indicates the target resource.
- An optional message body: Contains data for the request.

**HTTP Verbs**
Here are four basic HTTP verbs used in REST requests to interact with resources:

- GET: Retrieve a specific resource (by id) or a collection of resources.
- POST: Create a new resource.
- PUT: Update a specific resource (by id).
- DELETE: Remove a specific resource (by id).

**Paths**
Requests must contain a path to a resource that the operation should be performed on. 

In RESTful APIs, paths should be designed to help the client know what is going on.

Conventionally, the first part of the path should be the plural form of the resource. This keeps nested paths simple to read and easy to understand.

- Resource Naming: The first part of the path should be the plural form of the resource to keep paths readable and logical.

- Hierarchical Structure: For example, the path fashionboutique.com/customers/223/orders/12 clearly indicates accessing order id 12 for customer id 223, thanks to its hierarchical and descriptive structure.

- Specificity: Paths should provide the necessary information to locate a resource. For instance, a POST request to fashionboutique.com/customers does not need an id because the server generates it. Conversely, a GET request to fashionboutique.com/customers/:id retrieves a specific customer by id, and a DELETE request to the same path removes the specified customer.

By following these guidelines, RESTful APIs ensure clear and effective communication between clients and servers, fostering a robust and scalable architecture.

Happy hacking !