> For the complete documentation index, see [llms.txt](https://shimozurdo.gitbook.io/frontend/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shimozurdo.gitbook.io/frontend/principios-de-diseno-de-software/rest-api.md).

# REST API

Los principios de una **REST API** (Representational State Transfer Application Programming Interface) definen cómo debe estructurarse y comunicarse una API para ser eficiente, escalable y fácil de entender. REST es un estilo de arquitectura para diseñar sistemas distribuidos y utiliza HTTP para la comunicación entre cliente y servidor. Aquí están sus principios clave:

## 1. **Interfaz Uniforme**

* Define una forma estándar para que el cliente y el servidor se comuniquen, usando operaciones HTTP estándar como `GET`, `POST`, `PUT` y `DELETE`. Esto asegura que la interacción entre el cliente y el servidor sea consistente y predecible.
* **Ejemplo**:
  * `GET /products` para obtener una lista de productos.
  * `POST /products` para crear un nuevo producto.

## 2. **Desacoplamiento Cliente-Servidor**

* El cliente y el servidor están separados: el cliente solo necesita saber la URI para hacer la solicitud, y el servidor solo necesita procesar y responder sin depender de la implementación del cliente. Esto permite que ambos evolucionen de forma independiente.
* **Ejemplo**:
  * La interfaz de una app móvil puede ser diferente de una app web, pero ambas pueden comunicarse con la misma REST API.

## 3. **Sin Estado (Stateless)**

* Cada solicitud del cliente al servidor debe contener toda la información necesaria para entender y procesar la solicitud. Esto significa que el servidor no guarda ninguna información del estado entre solicitudes.
* **Ejemplo**:
  * Si un cliente realiza una solicitud `GET /orders/123`, debe incluir en la solicitud cualquier autenticación o contexto necesario, ya que el servidor no recuerda la sesión previa.

## 4. **Caché**

* Las respuestas de una REST API pueden indicar si son almacenables en caché, permitiendo que los clientes almacenen en caché las respuestas y las reutilicen en lugar de hacer múltiples solicitudes al servidor, reduciendo la carga en el servidor y mejorando el rendimiento.
* **Ejemplo**:
  * Una respuesta `GET /products` podría indicar al cliente que almacene la respuesta en caché durante una hora, evitando solicitudes repetitivas.

## 5. **Sistema en Capas (Layered System)**

* Una REST API puede estar compuesta por varias capas, permitiendo que haya intermediarios (como proxies, balanceadores de carga y firewalls) entre el cliente y el servidor. Esto permite mejorar la escalabilidad y seguridad del sistema.
* **Ejemplo**:
  * Una capa de autenticación podría ser añadida sin que el cliente tenga que saberlo.

## 6. **Código Bajo Demanda (opcional)**

* En algunos casos, el servidor puede proporcionar código ejecutable al cliente, como scripts JavaScript, que el cliente puede ejecutar para extender su funcionalidad. Este principio es opcional y no es común en todas las REST APIs.

## 7. **HATEOAS (Hypermedia as the Engine of Application State)**

* Este principio indica que las respuestas de la API deben incluir enlaces (hypermedia) a otros recursos relevantes, proporcionando una forma para que los clientes descubran rutas y operaciones adicionales en la API de manera dinámica.
* **Ejemplo**:
  * La respuesta a `GET /products/123` podría incluir un enlace para actualizar el producto (`PUT /products/123`) y otro para eliminarlo (`DELETE /products/123`).

#### Resumen

Los principios de REST ayudan a construir APIs que son flexibles, escalables y fáciles de mantener. Al adherirse a estos principios, se consigue una API que puede evolucionar sin afectar a los clientes, asegurando una comunicación robusta entre sistemas distribuidos.