REST significa Transferencia de Estado Representativo, un término acuñado por Roy Fielding en 2000. Es un estilo de arquitectura para diseñar aplicaciones acopladas libremente a través de HTTP, que se usa a menudo en el desarrollo de servicios web. REST no hace cumplir ninguna regla con respecto a cómo debe implementarse a un nivel inferior, solo pone directrices de diseño de alto nivel y le deja pensar en su propia implementación.
En mi último empleo, diseñé API RESTful para una importante empresa de telecomunicaciones durante dos buenos años. En este post, compartiré mis pensamientos aparte de las prácticas de diseño estándar. Puede que no estés de acuerdo conmigo en algunos puntos, y eso está perfectamente bien. Estaré encantado de discutir cualquier cosa con una mente abierta.
Comencemos con cosas específicas de diseño estándar para aclarar lo que ‘Roy Fielding’ quiere que construyamos. Luego discutiremos mis pensamientos, que serán más hacia puntos más finos mientras diseña sus API RESTful.
Restricciones arquitectónicas
REST define 6 restricciones arquitectónicas que hacen de cualquier servicio web una verdadera API RESTful.
- Interfaz uniforme
- Cliente–servidor
- Sin estado
- Cacheable
- Sistema en capas
- Código bajo demanda (opcional)
Interfaz uniforme
Dado que se aplica el nombre de restricción en sí, debe decidir la interfaz de API para los recursos dentro del sistema que se exponen a los consumidores de API y se siguen religiosamente. Un recurso en el sistema debe tener solo un URI lógico, y eso debe proporcionar una forma de obtener datos relacionados o adicionales. Siempre es mejor sinonimizar un recurso con una página web.
Un solo recurso no debe ser demasiado grande y contener todo en su representación. Siempre que sea relevante, un recurso debe contener enlaces (HATEOAS) que apunten a URI relativos para obtener información relacionada.
Además, las representaciones de recursos en todo el sistema deben seguir pautas específicas, como convenciones de nomenclatura, formatos de enlace o formato de datos (XML o JSON).
Todos los recursos deben ser accesibles a través de un enfoque común, como HTTP GET, y modificados de manera similar utilizando un enfoque coherente.
Cliente-servidor
Esta restricción esencialmente significa que la aplicación cliente y la aplicación servidor DEBEN poder evolucionar por separado sin ninguna dependencia entre sí. Un cliente solo debe conocer los URI de recursos, y eso es todo. Hoy en día, esta es una práctica estándar en el desarrollo web, por lo que no se requiere nada sofisticado de su parte. Hazlo simple.
Apátridas
Roy fielding consiguió la inspiración de HTTP, por lo que se refleja en esta restricción. Convierta todas las interacciones cliente-servidor en apátridas. El servidor no almacenará nada sobre la última solicitud HTTP realizada por el cliente. Tratará cada solicitud como nueva. Sin sesión, sin historial.
Si la aplicación cliente necesita ser una aplicación con estado para el usuario final, donde el usuario inicia sesión una vez y realiza otras operaciones autorizadas después de eso, cada solicitud del cliente debe contener toda la información necesaria para atender la solicitud, incluidos los detalles de autenticación y autorización.
Cacheable
En el mundo actual, el almacenamiento en caché de datos y respuestas es de suma importancia siempre que sea aplicable/posible. La página web que está leyendo aquí también es una versión en caché de la página HTML. El almacenamiento en caché mejora el rendimiento del lado del cliente y ofrece un mayor alcance de escalabilidad para un servidor, ya que la carga se ha reducido.
En REST, el almacenamiento en caché se aplicará a los recursos cuando corresponda, y luego estos recursos DEBEN declararse cacheables. El almacenamiento en caché se puede implementar en el servidor o en el lado del cliente.
Sistema en capas
REST le permite utilizar una arquitectura de sistema en capas en la que implementa las API en el servidor A y almacena datos en el servidor B y autentica solicitudes en el servidor C, por ejemplo. Normalmente, un cliente no puede saber si está conectado directamente al servidor final o a un intermediario en el camino.
Código bajo demanda (opcional)
Bueno, esta restricción es opcional. La mayoría de las veces, enviará las representaciones estáticas de recursos en forma de XML o JSON. Pero cuando lo necesite, puede usar return executable code para admitir una parte de su aplicación, por ejemplo, los clientes pueden llamar a su API para obtener un código de representación de widget de interfaz de usuario. Está permitido.
Observe que todas las restricciones anteriores están más estrechamente relacionadas con WWW (la web). Con las API RESTful, puede hacer lo mismo con sus servicios web que con las páginas web.