Arquitectura REST

REST (Representational State Transfer) es un estilo arquitectónico que se utiliza para la comunicación entre un cliente y un servidor, siendo un concepto fundamental en el desarrollo moderno de aplicaciones web.El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

Comunicación RESTful En una comunicación RESTful, el cliente accede al servidor a través de un punto de acceso, envía información y recibe un resultado. Generalmente, esta comunicación se realiza a través de HTTP (Hyper Text Transfer Protocol) en el puerto 80, lo que permite el acceso desde cualquier lugar. Los mensajes suelen enviarse en formato JSON, aunque también se puede utilizar XML, siendo JSON el formato preferido por su procesamiento nativo en clientes JavaScript.

1. El concepto de Recurso REST

¿Qué es un Recurso? . Un recurso hace referencia a un concepto importante de nuestro negocio (Facturas ,Cursos , Compras etc). Es lo que habitualmente se denomina un objeto de negocio.

2.Métodos HTTP y Operaciones CRUD (Verbos)

Los servicios RESTful utilizan los métodos estándar del protocolo HTTP para realizar operaciones sobre los recursos. Estos métodos se mapean comúnmente a las operaciones CRUD (Create, Read, Update, Delete):

• GET: Se utiliza para obtener (leer) una representación de un recurso o una colección de recursos.
  • Ejemplo: GET /usuarios (obtener todos los usuarios)
  • Ejemplo: GET /usuarios/123 (obtener el usuario con ID 123)
• POST: Se utiliza para crear un nuevo recurso. La información para el nuevo recurso se envía en el cuerpo de la solicitud.
  • Ejemplo: POST /usuarios (crear un nuevo usuario)
• PUT: Se utiliza para actualizar completamente un recurso existente o crear uno nuevo si no existe. La solicitud PUT es idempotente (múltiples solicitudes PUT idénticas tendrán el mismo efecto que una sola).
  • Ejemplo: PUT /usuarios/123 (actualizar el usuario con ID 123)
• PATCH: Se utiliza para actualizar parcialmente un recurso existente.
  • Ejemplo: PATCH /usuarios/123 (actualizar solo algunos campos del usuario con ID 123)
• DELETE: Se utiliza para eliminar un recurso.
  • Ejemplo: DELETE /usuarios/123 (eliminar el usuario con ID 123)

3. Principios Fundamentales de REST

Para que una API sea considerada RESTful, debe adherirse a una serie de principios arquitectónicos:

1. Cliente-Servidor: Existe una separación clara de responsabilidades entre el cliente (quien solicita los recursos) y el servidor (quien los provee). Esto mejora la portabilidad de la interfaz de usuario a través de múltiples plataformas y mejora la escalabilidad del servidor.
2. Sin Estado (Stateless): Cada solicitud del cliente al servidor debe contener toda la información necesaria para que el servidor la entienda. El servidor no debe almacenar ningún “estado” de la sesión del cliente entre solicitudes. Esto significa que cada solicitud es independiente y autónoma, lo que mejora la escalabilidad y la fiabilidad.
3. Caché (Cacheable): Las respuestas del servidor deben indicar si pueden ser cacheadas o no. Si una respuesta es cacheable, el cliente puede almacenar una copia de esa respuesta y reutilizarla para futuras solicitudes idénticas, lo que mejora el rendimiento y la eficiencia de la red.
4. Sistema en Capas (Layered System): Un sistema RESTful puede ser compuesto por múltiples capas de servidores intermediarios (proxies, balanceadores de carga, etc.) entre el cliente y el servidor final. Esto no debería afectar la interacción del cliente con el servidor, ya que el cliente no necesita saber cuántas capas intermedias existen.
5. Código Bajo Demanda (Code on Demand – Opcional): Este principio es opcional. Permite al servidor extender la funcionalidad del cliente transfiriéndole código ejecutable (por ejemplo, JavaScript). Aunque es parte del estilo arquitectónico de Fielding, no es comúnmente implementado en la mayoría de las APIs RESTful tradicionales.
6. Interfaz Uniforme (Uniform Interface): Este es el principio más importante y fundamental de REST. Es lo que realmente distingue a REST de otros estilos arquitectónicos y facilita la interacción entre diferentes sistemas. La interfaz uniforme se logra a través de cuatro restricciones:
   • Identificación de Recursos: Cada recurso debe ser identificable de forma única mediante una URI (Uniform Resource Identifier).
   • Manipulación de Recursos a través de Representaciones: Los clientes interactúan con los recursos obteniendo una “representación” del recurso (por ejemplo, JSON, XML) y enviando representaciones modificadas de vuelta al servidor para actualizar o crear recursos.
   • Mensajes Autodescriptivos: Cada mensaje del cliente o del servidor debe contener suficiente información para que el receptor entienda cómo procesar el mensaje. Esto incluye el tipo de medio (por ejemplo, application/json), los métodos HTTP y los códigos de estado.
   • HATEOAS (Hypermedia As The Engine Of Application State): Este es el aspecto más avanzado de la interfaz uniforme. Significa que las representaciones de los recursos deben incluir enlaces a otros recursos relacionados, guiando al cliente sobre las posibles transiciones de estado de la aplicación. Por ejemplo, la representación de un pedido podría incluir un enlace para “cancelar pedido” o “ver detalles del cliente”.

4. Códigos de Estado HTTP

Las respuestas del servidor incluyen un código de estado HTTP que indica el resultado de la solicitud. Algunos de los códigos más comunes son:

• 2xx (Éxito):
  • 200 OK: La solicitud fue exitosa.
  • 201 Created: El recurso fue creado exitosamente (típicamente después de un POST).
  • 204 No Content: La solicitud fue exitosa, pero no hay contenido que devolver.
• 3xx (Redirección):
  • 301 Moved Permanently: El recurso se ha movido permanentemente.
• 4xx (Error del Cliente):
  • 400 Bad Request: La solicitud es incorrecta o mal formada.
  • 401 Unauthorized: Se requiere autenticación.
  • 403 Forbidden: El cliente no tiene permisos para acceder al recurso.
  • 404 Not Found: El recurso solicitado no existe.
  • 405 Method Not Allowed: El método HTTP utilizado no está permitido para el recurso.
  • 409 Conflict: Conflicto en el estado actual del recurso (ej. intento de crear un recurso que ya existe).
  • 429 Too Many Requests: El cliente ha enviado demasiadas solicitudes en un período de tiempo.
• 5xx (Error del Servidor):
  • 500 Internal Server Error: Un error inesperado ocurrió en el servidor.
  • 503 Service Unavailable: El servidor no está disponible temporalmente.

Niveles de REST

La arquitectura REST se puede entender en diferentes niveles de madurez:

• Nivel 0: El Caos En este nivel, la información se accede en un formato de datos puro, típicamente XML o JSON, sin mucha organización. Es una etapa inicial y desordenada en la que no hay una estructura clara para el manejo de los recursos.
• Nivel 1: Recursos Este nivel introduce el concepto de “Recursos”, que son conceptos de negocio importantes como facturas, cursos o compras. Esto proporciona un primer nivel de organización, permitiendo el acceso independiente a cada recurso. Promueve la reutilización, aumenta la flexibilidad y permite operaciones básicas como inserción, eliminación y búsqueda para cada recurso.
• Nivel 2: Verbos HTTP En este nivel, las operaciones se categorizan estrictamente utilizando los métodos HTTP estándar:
  • GET: Se utiliza para consultar o recuperar recursos.
  • POST: Se emplea para insertar nuevos recursos.
  • PUT: Se usa para actualizar recursos existentes.
  • DELETE: Se utiliza para eliminar recursos. La mayoría de las arquitecturas REST actuales operan en este nivel, proporcionando una forma clara y estandarizada de interactuar con los recursos.
• Nivel 3: HATEOAS (Hypertext As The Engine Of Application State) Este es el nivel más avanzado de REST y tiene como objetivo reducir el acoplamiento entre el cliente y el servidor. En lugar de que el cliente necesite conocer todas las URLs de los recursos relacionados, el propio recurso proporciona enlaces a otros recursos relacionados. Por ejemplo, un recurso “Alumno” podría incluir un enlace a sus “Cursos”, permitiendo al cliente navegar directamente sin conocimiento previo de la URL del curso. Esto aumenta la flexibilidad y reduce la dependencia entre las partes.

5. Ventajas de REST

• Simplicidad y Facilidad de Uso: Utiliza los métodos HTTP existentes, lo que lo hace fácil de entender e implementar.
• Escalabilidad: El principio de “sin estado” facilita la escalabilidad horizontal de los servidores.
• Flexibilidad: Permite a los clientes interactuar con los recursos utilizando diferentes lenguajes y plataformas.
• Portabilidad: La separación cliente-servidor permite que la interfaz de usuario se desarrolle de forma independiente del backend.
• Rendimiento: El uso de caché puede mejorar significativamente el rendimiento.
• Interoperabilidad: Ampliamente adoptado, lo que facilita la integración entre diferentes sistemas.

6. Desventajas de REST

• Sobrefetching/Underfetching: A veces, las APIs REST pueden devolver demasiada o muy poca información en una sola solicitud, lo que requiere múltiples solicitudes o procesar datos innecesarios. Tecnologías como GraphQL buscan abordar esto.
• Falta de Tipado Estricto: Al depender de HTTP y JSON/XML, no hay un tipado estricto intrínseco, lo que puede requerir una validación cuidadosa en el cliente y el servidor.
• Complejidad de HATEOAS: Aunque es un principio clave, la implementación completa de HATEOAS puede ser compleja y no siempre se aplica en todas las APIs RESTful.