Un diseño RESTful mejora el rendimiento API, reduce los esfuerzos de desarrollo y reduce el soporte operativo necesario a través del desarrollo de aplicaciones, servicios y API web. Gracias a restricciones RESTful demostrables, los equipos podrán crear sistemas escalables, omnipresentes y prolíficos.
REST requiere una mentalidad de desarrollo nueva, por lo que muchas implementaciones de API no están realmente basadas en restricciones o principios REST, ni cumplen con expectativas de escalabilidad, actualización o interoperabilidad. Si seguimos buenas prácticas y trabajamos con herramientas RESTful, los equipos podrán diseñar, actualizar y conectar API RESTful.
REST restringe el sistema a:
- Interacciones de cliente-servidor
- Comunicaciones sin estado
- Datos cacheables
- Interfaces uniformes
- Sistemas por capas
- Código bajo demanda
-Puede que te interese: REST vs. SOAP-
Cada restricción aporta propiedades beneficiosas al sistema web. Al implementar restricciones, los equipos pueden construir sistemas sencillos, fiables, factibles, utilizables y accesibles que podrán actualizar y mantener con facilidad. En la siguiente tabla mostramos cómo las restricciones REST pueden mejorar las propiedades de nuestro sistema:
| Al implementar esta restricción: | Conseguimos las siguientes características de sistema: |
| Cliente-servidor | Sencillo, escalable, actualizable |
| Sin estado | Sencillo, visible, fácil de mantener, fiable y actualizable |
| Cache | Visible, escalable y eficiente |
| Interfaz / Contratos uniformes | Sencillo, utilizable, visible, accesible, actualizable y fiable |
| Sistema por capas | Flexible, escalable, fiable y eficiente |
| Código bajo demanda | Actualizable |
Tabla 1: Restricciones REST y propiedades del sistema
Cuando desarrolles API, aplicaciones o servicios web, los programadores aplican restricciones REST de forma desigual. Por ejemplo, puede que una aplicación web tenga código bajo demanda (p. ej., JavaScript por el lado del cliente), un sistema por capas e interacciones de cliente-servidor, pero, por otro lado, puede que no implemente interfaces de manera uniforme ni datos cacheables.
«Si el botón ‘atrás’ no funciona, tu aplicación web o API no es verdaderamente RESTful».
Puede que las API implementen interfaces uniformes, interacciones de cliente-servidor y sistemas por capas, pero puede que no implementen comunicaciones sin estado ni datos cacheables. Si tu cliente de la API debe involucrarse con sesiones sticky, o si tu servidor no comprueba el último encabezado modificado antes de reaccionar, tu API no es completamente RESTful.
Comunicaciones sin estado
Cuando las comunicaciones son sin estado, cada solicitud tiene lugar de forma aislada y el cliente es el responsable de mantener el estado. La solicitud del cliente contiene toda la información necesaria para el proceso de solicitud y el servidor RESTful no almacena información de estado local de solicitudes anteriores.
Puedes hacer una prueba de fuego para comunicaciones sin estado al desactivar las cookies de sesión y determinar si la API o el servicio web todavía funcionan como estaba previsto.
Las API, los servicios y las aplicaciones RESTful todavía pueden revelar estados. Sin embargo, la información del estado debe estar integrada en las representaciones de hipervínculos (p. ej., URLs, hrfs, mensajes…). Al transferir el estado del cliente explícitamente, el cliente final recibirá un mensaje de respuesta explícito desde un camino operativo válido a través del sistema.
Con las comunicaciones sin estado, el contexto compartido temporalmente no queda almacenado en el servidor. Ya que el sistema debe enviar el contexto temporal del estado de forma reiterada en las solicitudes, las comunicaciones sin estado incrementan el tráfico de la red. Sin embargo, el incremento en la conectividad de la red hace que los beneficios pesen más que los inconvenientes.
Datos cacheables
Los sistemas RESTful identifican los datos como cacheables y respetan las etiquetas cache. Los datos cacheables reducen el tráfico de la red y la carga sobre el sistema back-end. Los nodos intermediarios pueden devolver datos cacheados para el beneficio de los servidores back-end, por lo que mejoran la escalabilidad, la disponibilidad, la fiabilidad y el rendimiento. En un sistema RESTful, los intermediarios reconocen la información nueva, operaciones idempotentes (p. ej., GET) y versiones de esquema.
Interfaces uniformes
Aunque la restricción de interfaces uniformes es la más decisiva y visible de REST, suele ser el motivo más frecuente por el que no se cumple íntegramente con los principios y las técnicas RESTful.
Interfaces uniformes:
- Recursos de identidad
- Manipular recursos a través de representaciones
- Mostrar mensajes autodescriptivos
- Basarse en hipermedia como motor del estado de la aplicación (Hypermedia As The Engine Of Application State, HATEOAS)
Las interfaces uniformes deberían identificar el comportamiento y la semántica del mensaje sin ver el cuerpo del mensaje. El URL o URI deben declarar que el recurso no está siendo manipulado. Las interfaces uniformes no dependen del estado de los mensajes que almacenan. Las interfaces uniformes están basadas en mensajes estándar (p. ej., GET, HEAD, POST, DELETE) y comunican información de tipo de medio de procesos.
Cuando aplicas capas de restricción de REST sobre HTTP y URLs, los sistemas RESTful se ven optimizados a través de la transferencia de datos, aunque sean insuficientes para otras interacciones.
Sistemas por capas
A través de la creación de sistemas por capas, los equipos podrán actualizar componentes de cliente y de servidor de forma independiente. Un patrón de diseño API (API Façade) oculta la complejidad de la implementación interna y presenta una interfaz sencilla a los clientes. Las interfaces sencillas de API RESTful ocultan múltiples bases de datos de back-end y servicios adicionales (véase la figura 1).
A través del uso de un patrón de diseño API (API Façade), los equipos podrán conectarse fácilmente a sistemas existentes a través de técnicas de meditación complejas, pero también al ofrecer una API sencilla y fácil de usar a sus clientes. A nivel técnico, la solución podrá unir y organizar servicios y transformar mensajes.
El patrón de diseño API (API Façade) permite que los equipos escalen cada capa de la arquitectura de forma independiente, y que apliquen políticas de infraestructura (p.ej. autorizaciones, autenticaciones, tiempos de respuesta, y tasas límite) por servicio de sistema o por API. API Façade puede limitar la complejidad del sistema e incluso simplificar aún más la complejidad de la integración al implementar principios y restricciones RESTful en el patrón de diseño de la API.
Figura 1: Patrón API Façade
Código bajo demanda
El código bajo demanda permite que los clientes extiendan las funcionalidades a través de la descarga y la ejecución local del código. Al activar el código bajo demanda, el sistema reduce el número de características pre-implementadas necesarias y mejora la actualización del sistema. Al descargar y ejecutar JavaScript por el lado del cliente o en plugins dentro de un servidor o del cliente REST cumplimos con las restricciones REST.
El uso de restricciones REST puede facilitar el trabajo del equipo y mejorar nuestros sistemas de forma significativa. Un diseño RESTful hará que nuestras API y servicios web sean más eficientes, y que nuestros esfuerzos de desarrollo se reduzcan considerablemente. ¿Quieres conseguir un diseño RESTful? Descárgate nuestra guía.
