Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuándo es una API realmente REST frente a REST?

 


Representational State Transfer (REST) ​​es uno de los mejores estilos de diseño de API que existen. Originalmente se definió en el Ph.D. de Roy Fielding. disertación del año 2000, y desde entonces ha sido un elemento básico de la economía API ... ¡o eso nos gusta decirnos! De hecho, muchas de las API "REST" del mundo no cumplen con uno o más de los criterios que definen el estilo. Si bien estas API similares a REST son sencillas de crear y consumir, algunos dicen que no ofrecen los mismos beneficios que ofrecería una API REST pura. En este artículo, veremos de cerca en qué se diferencia una verdadera API REST de una API similar a REST y analizaremos los pros y los contras de esas características diferenciadoras.

REST frente a API similares a REST

Según Zdenek Nemec, autor del lenguaje de descripción API Blueprint , la diferencia clave entre REST y las API similares a REST es que esta última no cumple una restricción definitoria de REST: interfaz uniforme . Como tal, establecer las distinciones teóricas y prácticas entre estos dos estilos de API requiere una comprensión detallada de la interfaz uniforme .

¿Qué es la interfaz uniforme?

Comencemos analizando la interfaz uniforme en un nivel literal. Con cualquier API, la interfaz es lo que ve el cliente cuando interactúa con la API. REST exige que esto sea uniforme (léase: coherente), de modo que un cliente que consuma la API, o una nueva versión de la misma API, por primera vez pueda saber intuitivamente cómo interactuar con ella.

En su disertación, Fielding escribe:

“Para obtener una interfaz uniforme, se necesitan múltiples restricciones arquitectónicas para guiar el comportamiento de los componentes. REST se define por cuatro restricciones de interfaz: identificación de recursos; manipulación de recursos a través de representaciones; mensajes autodescriptivos; e hipermedia como motor del estado de la aplicación ".

Así es, la interfaz uniforme en sí misma consta de cuatro restricciones. Aquí se explican:

Identificación de recursos

La primera restricción de la interfaz uniforme es cómo se identifican los recursos. Esto significa que las API REST deberían permitir a los clientes identificar un recurso por medio de un URI contenido en la solicitud.

Algunos agregan que la representación de un recurso devuelto al cliente debe estar separada del recurso en sí. En otras palabras, la representación RESTful de un recurso no debe representar la representación interna del servicio de ese recurso, asumiendo que los dos son diferentes.

Manipulación de recursos a través de representaciones

La segunda restricción de la interfaz uniforme es la manipulación de recursos a través de sus representaciones. Específicamente, dada la representación de un recurso y cualquier metadato asociado con él, el cliente debería poder modificar o eliminar el recurso.

En la práctica, esto realmente solo significa los métodos HTTP disponibles. El DELETEmétodo debe permitir a los clientes eliminar un recurso que tiene solo su URI, mientras que los métodos PUTPATCHdeben permitir a los clientes modificar un recurso que tiene su URI y representación.

Este enfoque para manipular recursos elimina los puntos finales de API largos y basados ​​en verbos (por ejemplo updateUserAddress), en lugar de proporcionar una alternativa uniforme ... ¡por lo tanto, es parte de una interfaz uniforme!

Mensajes autodescriptivos

La tercera restricción de la interfaz uniforme es que los mensajes son autodescriptivos. Esto significa que la representación de un recurso debe devolverse al cliente junto con información sobre cómo procesarlo.

Con las API REST, el encabezado HTTP Content-Type debe usarse para decirle al cliente qué tipo de medio se envía en el cuerpo. En aras de la estandarización, idealmente debería ser un tipo de medio registrado por IANA , como application/jsonuna respuesta JSON. También se pueden utilizar tipos de medios que no pertenecen a la IANA, pero deben acordarse con los clientes.

Hipermedia como motor del estado de la aplicación (HATEOAS)

La cuarta y última restricción de la interfaz uniforme es que el estado de la aplicación debe expresarse dinámicamente a través de hipermedia (conocido en forma abreviada como HATEOAS ). Esto significa que, además de devolver una representación del recurso en cuestión, una solicitud también debe cumplirse con instrucciones sobre cómo interactuar más con el recurso o la API en su conjunto.

En particular, al acceder a un recurso, el cliente debe recibir información sobre las acciones que se pueden realizar en ese recurso. Estas acciones deben ir acompañadas de referencias de hipervínculos a URI relevantes.

Lea también: Diseño de una verdadera máquina de estados REST

HATEOAS: La restricción definitoria de REST

Si observa los primeros tres componentes de la interfaz uniforme: identificación de recursos; manipulación de recursos a través de representaciones; y mensajes autodescriptivos: notará que la mayoría de las API similares a REST abordan con éxito estos problemas:

  • Los URI se utilizan para identificar recursos
  • Los recursos se pueden manipular (intuitivamente) teniendo sus representaciones
  • Las respuestas son autodescriptivas, generalmente gracias al encabezado Content-Type

De hecho, es la última de estas limitaciones, HATEOAS , la que impide que muchas API obtengan el glorioso título de una API REST. Si bien estas API de tipo REST están estructuradas en torno a recursos y ofrecen una gran cantidad de bases HTTP para su uso, no navegan por los clientes a través de la interfaz mediante hipervínculos.

Curiosamente, este uso de hipermedia es también lo que define el tercer nivel del Modelo de Madurez de Richardson para evaluar API.

Pros y contras de HATEOAS; o API REST frente a API similares a REST

Si una API es realmente una API REST o simplemente similar a REST, se reduce a si implementa HATEOAS. Entonces, para comparar los dos estilos, todo lo que tenemos que hacer es observar los pros y los contras del uso de hipermedia.

Pros

Evolvability: Tener clientes de forma dinámica interactuar con su API hace que sea mucho más fácil para evolucionar su API - se puede modificar o funcionalidad movimiento sin la necesidad del control de versiones
(ver esta Tweet)
Discoverability: los clientes se sabe qué medidas adicionales están disponibles permite la detección eficaz de la funcionalidad ofrecida dentro de su API, reduciendo la necesidad de documentación detallada
Simplicidad: decirle a los clientes qué acciones adicionales están disponibles minimiza la lógica del lado del cliente, agilizando y simplificando la integración

Contras:

La falta de adopción: Debido a los viejos hábitos y la falta de herramientas y estándares, la mayoría de los clientes no van a consumir su API dinámicamente
desarrollo necesita: Implementación de hipermedia alarga el proceso de desarrollo, el aumento de los costos y el tiempo de comercialización
Dependencias: Haciendo uso de marcos hipermedia, como Hydra , Siren o JSON Hyper-Schema pueden introducir nuevas dependencias en la API.

Con todo, el verdadero enfoque REST promete beneficios significativos, sobre todo, una capacidad de evolución ilimitada, gracias a su uso de hipermedia. Sin embargo, en la práctica, las API de tipo REST a menudo satisfacen las necesidades de los clientes sin los desafíos de desarrollo adicionales.

Relacionado: Vea a Tomasz Pluskiewicz de Zazuko recorrer una implementación de API REST impulsada por Hydra.

Pensamientos finales

La diferencia clave entre REST y las API similares a REST radica en la restricción de la interfaz uniforme, en particular, hipermedia como motor del estado de la aplicación. Mientras que el verdadero REST, por definición, exige el uso de hipervínculos para navegar a los clientes a través de la interfaz, las API similares a REST no lo hacen y, por lo general, cumplen con todas las restricciones restantes del estilo. El hipermedia como motor del estado de la aplicación es claramente un ideal interesante, pero carece de practicidad tanto en la adopción como en la implementación.

Publicar un comentario

0 Comentarios