REST - Representational State Transfer

Las APIs RESTful (Interfaz de Programación de Aplicaciones basada en Transferencia de Estado Representacional) son un enfoque arquitectónico para el diseño de servicios web que utiliza los principios y restricciones del estilo de arquitectura REST. REST es un acrónimo que significa Transferencia de Estado Representacional y fue propuesto por Roy Fielding en su tesis de doctorado en 2000.

Para que una API sea clasificada como RESTful, debe adherirse a ciertos principios esenciales:

• 1. Estructura Cliente-Servidor: La arquitectura debe estar claramente dividida entre clientes, servidores y los recursos que estos intercambian, utilizando HTTP para las peticiones de los clientes.
• 2. Comunicación sin estado: Cada petición del cliente al servidor debe contener toda la información necesaria para entenderla, sin que el servidor necesite recordar solicitudes previas.
• 3. Almacenamiento en caché de datos: Los datos se pueden guardar en caché para mejorar la eficiencia de las solicitudes, reduciendo la carga en el servidor y acelerando la respuesta al cliente.
• 4. Interfaz Uniforme: Para asegurar la estandarización en la transferencia de información, se deben seguir ciertas normas:

REST (Representational State Transfer)

Las API REST son fundamentales en el desarrollo de software, simplificando la comunicación entre servicios web. Su arquitectura Cliente-Servidor, escalabilidad e independencia las hacen versátiles para diversas aplicaciones. Actualmente, la mayoría de empresas que se dedican a la creación de software utilizan API REST para crear y conectar diferentes servicios

Aquí tienes ejemplos prácticos para GET, POST, PUT, y DELETE, junto con otros verbos HTTP y funcionalidades adicionales que puedes implementar en APIs:   

GET

Objetivo: Obtener información de un recurso.  Ejemplo: Obtener una lista de usuarios

GET /usuarios HTTP/1.1
Host: api.misitio.com 

Respuesta

 [
  {
    "id": 1,
    "nombre": "Juan Pérez",
    "email": "juan@example.com"
  },
  {
    "id": 2,
    "nombre": "Ana López",
    "email": "ana@example.com"
  }
]

POST

Objetivo: Crear un nuevo recurso.  Ejemplo: Crear un nuevo usuario

POST /usuarios HTTP/1.1
Host: api.misitio.com
Content-Type: application/json

{
  "nombre": "Carlos García",
  "email": "carlos@example.com"
}

Respuesta

 {
  "id": 3,
  "nombre": "Carlos García",
  "email": "carlos@example.com"
}

PUT

Objetivo: Actualizar un recurso existente (reemplaza toda la información). Ejemplo: Actualizar la información de un usuario

PUT /usuarios/1 HTTP/1.1
Host: api.misitio.com
Content-Type: application/json

{
  "nombre": "Juan Pérez Actualizado",
  "email": "juan.actualizado@example.com"
}

Respuesta

 {
  "id": 1,
  "nombre": "Juan Pérez Actualizado",
  "email": "juan.actualizado@example.com"
}

DELETE

Objetivo: Eliminar un recurso.  Ejemplo: Eliminar un usuario por ID

DELETE /usuarios/1 HTTP/1.1
Host: api.misitio.com

Respuesta

 {
  "mensaje": "Usuario eliminado con éxito"
}

Otros verbos HTTP:

PATCH: Similar a PUT, pero solo actualiza una parte del recurso.

• Ejemplo: Actualizar el correo de un usuario

PATCH /usuarios/1 HTTP/1.1
Host: api.misitio.com
Content-Type: application/json

{
  "email": "nuevo.email@example.com"
}

OPTIONS: Obtiene información sobre los métodos soportados por un servidor.

• Ejemplo:

OPTIONS /usuarios HTTP/1.1
Host: api.misitio.com

 Allow: GET, POST, PUT, DELETE, OPTIONS 

HEAD: Similar a GET, pero solo devuelve los encabezados y no el cuerpo de la respuesta.

• Esto se usa para verificar si un recurso existe.

 

Otras funciones que se pueden implementar:

Autenticación y Autorización:

• Usa tokens (como JWT) o claves API para proteger tu API.

Filtrado y paginación:

• Permite buscar y limitar resultados. Por ejemplo:

GET /usuarios?nombre=Juan&pagina=1&limite=10 

 Webhooks:

• Envía notificaciones automáticas cuando ocurre un evento (por ejemplo, cambios en datos).

 Caché:

• Responde más rápido reutilizando respuestas anteriores con encabezados como Cache-Control.