¿REST y HATEOAS son una buena arquitectura para los servicios web?

15

Si entiendo correctamente, REST fue formalizado por Roy Fielding como modelo descriptivo de la arquitectura de la web. AFAIK Fielding no afirmó que REST fuera bueno, solo estaba describiendo la arquitectura de facto de la web. La web ya había demostrado en este punto un enorme y exitoso sistema de hipertexto distribuido, por lo que este tipo valida REST como una arquitectura exitosa para el dominio de hipermedia distribuido principalmente navegado y consumido por humanos.

Los servicios web REST se crearon aplicando la arquitectura REST a las API. Pero, ¿hay alguna razón para pensar que REST es una arquitectura deseable para este dominio? Más específicamente, ¿hay alguna evidencia de que HATEOAS sea un principio de diseño beneficioso para la comunicación de máquina a máquina?

Mi preocupación es que HATEOAS tiene sentido para hipermedia porque hay pocos tipos de contenido conocidos (HTML, imágenes, video, etc.) y el cliente sabe cómo consumirlos. Pero para las API, los tipos de contenido son muy específicos y el cliente solo puede consumirlos de manera significativa si el cliente está específicamente programado para consumirlos. Devolver una URL al cliente no hace que el cliente pueda consumir el recurso indicado.

JacquesB
fuente
2
Dado que la web se basa en el uso de HTTP y REST es HTTP, creo que es una excelente opción.
Rob
1
@Rob: REST más que HTTP. Por ejemplo, SOAP y XML-RPC también usan HTTP pero no se ajusta a REST.
JacquesB
Tampoco se basa en la arquitectura REST. De ahí la diferencia.
Rob
44
Es una pregunta realmente difícil. Porque finalmente es tan bueno o malo como cualquier tecnología anterior o actual. Depende de tu tarea. Para algunas tareas funciona. Para otros, vamos a Graphql o Falcor / JSONGraph. O incluso el binario (gRPC) está de moda nuevamente. Desde mi perspectiva, la promesa de HATEOAS y los "clientes inteligentes" no funcionó. Arriba lo mató.
Thomas Junk
Depende de muchas cosas. No todos son problemas técnicos. El contexto que involucra la implementación y la ejecución es importante.
Laiv

Respuestas:

15

AFAIK Fielding no afirmó que REST fuera bueno, solo estaba describiendo la arquitectura de facto de la web.

Eso lo vende un poco, creo. REST es, después de todo, una enumeración del estilo arquitectónico que Fielding estaba usando como arquitecto jefe de la especificación HTTP / 1.1 .

Pero, ¿hay alguna razón para pensar que REST es una arquitectura deseable para este dominio? ¿Hay alguna evidencia que diga que HATEOAS es un principio de diseño beneficioso para la comunicación de máquina a máquina?

"Depende". HATEOAS es parte de la restricción de interfaz uniforme de REST.

Al aplicar el principio de generalidad de ingeniería de software a la interfaz del componente, se simplifica la arquitectura general del sistema y se mejora la visibilidad de las interacciones. Las implementaciones están desconectadas de los servicios que brindan, lo que fomenta la capacidad de evolución independiente. Sin embargo, la desventaja es que una interfaz uniforme degrada la eficiencia, ya que la información se transfiere de forma estandarizada en lugar de una que sea específica para las necesidades de una aplicación. La interfaz REST está diseñada para ser eficiente para la transferencia de datos hipermedia de gran tamaño, optimizando para el caso común de la Web, pero dando como resultado una interfaz que no es óptima para otras formas de interacción arquitectónica.

Así que pensemos por un momento sobre lo que esto significa. Cuando tengo problemas con mi enrutador inalámbrico, puedo comunicarme con él utilizando el mismo navegador que utilizo para enviar respuestas a stackexchange. En particular, no importa qué navegador esté usando o si mi navegador tiene algunas actualizaciones detrás (o delante) de lo que espera el enrutador. No importa que la organización de ingeniería que escribió el navegador sea completamente independiente de la organización que creó la interfaz del enrutador.

Eso simplemente funciona .

No es, por supuesto, universal. Fielding, en 2008 , escribió:

Eso no significa que creo que todos deberían diseñar sus propios sistemas de acuerdo con el estilo arquitectónico REST. REST está destinado a aplicaciones basadas en la red de larga duración que abarcan varias organizaciones. Si no ve la necesidad de las restricciones, no las use.

Las restricciones que forman el estilo arquitectónico REST fueron elegidas por las propiedades que inducen; Si esas propiedades no son valiosas para su caso de uso, entonces debería considerar descartar las restricciones correspondientes.

Donde máquina a máquina se vuelve difícil, es que has perdido la capacidad del ser humano de igualar difusamente la semántica proporcionada por las representaciones. Los clientes pueden sobrevivir conociendo solo los tipos de medios, pero normalmente tenemos un ser humano mirando las señales semánticas para obtener significado.

schema.org es una parte de un esfuerzo por crear un vocabulario legible por máquina; los agentes de la máquina usan al cliente para encontrar las sugerencias semánticas y aplican su propia comprensión del significado para elegir las acciones correctas a tomar.

Pero es trabajo; debe invertir en el desarrollo de representaciones amigables para la máquina de sus recursos y garantizar que esas representaciones sigan siendo compatibles con versiones anteriores y posteriores, de modo que los clientes puedan desarrollarse de forma independiente.

Cuando una sola organización controla tanto al cliente como al servidor, los beneficios de esta independencia son mucho menores, en cuyo caso la restricción puede no ser una opción arquitectónica apropiada.

VoiceOfUnreason
fuente
Interesante respuesta. Parece, especialmente en base a esta cita " La interfaz REST está diseñada para ser eficiente para la transferencia de datos hipermedia de gran tamaño, optimizando para el caso común de la Web, pero resultando en una interfaz que no es óptima para otras formas de interacción arquitectónica. "que Fielding no consideraría la arquitectura REST óptima para las API de servicio. (¡Por supuesto que REST sigue siendo mejor que SOAP, incluso si no es óptimo!)
JacquesB
Es difícil decir qué Fielding consideraría óptimo :-). Supongo que algunas necesidades de API incluyen la transferencia de datos hipermedia de gran tamaño.
Laiv
6

No, 'DESCANSO completo' no es tan bueno.

Como lo demuestra la falta de personas que implementan HATEOS en sus API y los interminables argumentos sobre qué verbo HTTP utilizar para una llamada en particular.

Pero debes reconocer por qué REST es tan popular. Antes de su adopción, había varios protocolos locos y complicados, como ebXML y SOAP, que incluían reconocimientos, tiempos de espera, ID de conversación y estado.

Poner estas cosas en marcha y luego explicar a los consumidores de la API fue una tarea difícil. "¿Por qué no hago un GET con la identificación que quiero en la cadena de consulta y me envías los datos?" Era una pregunta obvia y común.

Luego, el segundo problema era XML, JavaScript no lo entendía, los esquemas eran un fastidio y terminaría con enormes archivos txt que consisten principalmente en <MyLongObjectName>. Entonces la gente comenzó a usar JSON en su lugar.

Ahora REST tiene un poco de culto a su alrededor, pero debido a que las reglas son tan vagas, no evita que desactive una API utilizable que es lo suficientemente simple como para que los consumidores 'solo la obtengan' y la usen sin un plazo de 6 meses de embarque. proceso.

Ewan
fuente
Una de las quejas más frecuentes de Fielding es la falta de comprensión de REST y la implementación adecuada de las personas. Esto no es un fallo de REST. La falla de Javascript con XML tampoco es un problema con REST. Y Javascript y XML tampoco tienen nada que ver con REST. Que Fielding se había hecho disponible en línea, escribió artículos fuera de su disertación, señaló ejemplos del uso adecuado de REST, y la gente parecía no tener problemas para comprender su escritura e implementación de HTTP, parece mostrar que no debería haber muchos problemas para entender e implementando adecuadamente REST.
Rob
XML no tiene relación con si REST es una buena arquitectura API o no, no hay nada en el estándar que requiera XML como formato de recurso. JSON, HTML, texto sin formato son recursos válidos, entre otros.
Paul
2
Creo que cuando hablamos de REST debemos reconocer cuál es el estándar Y qué implementan las personas en la realidad y luego LLAMAR 'REST'
Ewan
2

Es para señalar que Roy no fue el inventor original de la mayoría de los principios de REST, reúne muchos principios que se sabe que funcionan en sistemas anteriores para resolver varios problemas específicos. REST es simplemente la conclusión natural de aplicar estos principios en una sola arquitectura.

Incluso antes de que Roy Fielding escribiera su disertación sobre REST , el HTTP ya estaba diseñado en torno a los principios que más tarde se conocerían como REST. En la conclusión de su disertación , escribió:

Al comienzo de nuestros esfuerzos dentro del Grupo de trabajo de ingeniería de Internet para definir el Protocolo de transferencia de hipertexto existente (HTTP / 1.0) [19] y diseñar las extensiones para los nuevos estándares de HTTP / 1.1 [42] e Identificadores uniformes de recursos (URI) [21] ], Reconocí la necesidad de un modelo de cómo debería funcionar la World Wide Web. Este modelo idealizado de las interacciones dentro de una aplicación web general, conocido como el estilo arquitectónico de Transferencia de estado representacional (REST), se convirtió en la base de la arquitectura web moderna, proporcionando los principios rectores por los cuales se podían identificar fallas en la arquitectura preexistente y extensiones validado antes del despliegue .

REST and HATEOS es una buena opción para el problema para el que fue diseñado:

REST es un conjunto coordinado de restricciones arquitectónicas que intenta minimizar la latencia y la comunicación de red, al mismo tiempo que maximiza la independencia y la escalabilidad de las implementaciones de componentes . Esto se logra colocando restricciones en la semántica del conector donde otros estilos se han centrado en la semántica de componentes. REST permite el almacenamiento en caché y la reutilización de interacciones, la sustituibilidad dinámica de componentes y el procesamiento de acciones por parte de intermediarios , satisfaciendo así las necesidades de un sistema hipermedia distribuido a escala de Internet.

Sin embargo, debe tenerse en cuenta que la Web y REST no son necesariamente una buena opción para todos los problemas:

Del mismo modo, las extensiones propuestas se pueden comparar con REST para ver si se ajustan a la arquitectura; de lo contrario, es más eficiente redirigir esa funcionalidad a un sistema que se ejecuta en paralelo con un estilo arquitectónico más aplicable.

Entonces, si su pregunta es "¿REST y HATEOAS son una buena arquitectura para los servicios web?" entonces, la respuesta es simplemente "sí, es una buena arquitectura para servicios web". El problema realmente es si todos los problemas que las personas intentaron resolver al adaptarlos a las restricciones web, realmente deberían haber sido los servicios web en primer lugar.

Hay muchas API que realmente no se ajustan a REST. Las API que no necesitan el tipo de escalabilidad que REST está diseñado para resolver, no son consumidas por varias organizaciones que pueden evolucionar de forma independiente y no necesitan ser duraderas; para estos problemas, las restricciones REST son solo una camisa de fuerza.

Pero, ¿hay alguna razón para pensar que REST es una arquitectura deseable para este dominio? Más específicamente, ¿hay alguna evidencia de que HATEOAS sea un principio de diseño beneficioso para la comunicación de máquina a máquina?

La evidencia es el éxito de la Web para resolver los problemas de muchas personas. REST es una arquitectura híbrida, que combina los diseños de muchos estilos arquitectónicos anteriores. Muchos dominios problemáticos no tienen todos los requisitos de la Web y no necesitan obedecer todas las restricciones de REST para funcionar bien. Es por eso que hay muchas arquitecturas exitosas que funcionan bien simplemente aplicando algunas partes de REST pero no otras. HATEOAS y la Interfaz Uniforme, por ejemplo, son principios que a menudo son omitidos por las API que no necesitan cruzar los límites y sistemas de la organización que tienen un período de desaprobación relativamente corto.

Lie Ryan
fuente
2

En la presentación de Fielding en Adobe Experience Manager:

¡REST NO es una arquitectura!

El descanso es un estilo arquitectónico, que es la abstracción de la arquitectura diferente que existe en Internet.

REST es una acumulación de restricciones de diseño para inducir propiedades arquitectónicas.

REST es una palabra de moda, y todos quieren tener API RESTful. En realidad, cuando las personas se enfrentaron a restricciones REST, dejaron caer algunas de estas restricciones porque no era necesario o no obtener ningún beneficio para aplicar todas las restricciones.

Como mencionó, HATEOAS es útil cuando el cliente es un navegador web. Cuando el cliente es una aplicación móvil, quizás no tanto. Sería una buena práctica, pero también hay costos asociados con el diseño de una aplicación como esa, tanto que, por poner un ejemplo, el equipo de aplicaciones móviles y el equipo de back-end simplemente acordaron eliminar esa restricción. Y eso tiene sentido porque ambos equipos no están tan poco unidos porque trabajan para la misma compañía.

DESCANSO en AEM

imel96
fuente
0

Si lo que desea es crear un servicio que sea consumido por otro servidor, entonces xmlrpc es la opción correcta. Si lo que desea es un servicio para clientes delgados o dispositivos de baja potencia ... o clientes desconocidos a través de Internet abierto, quizás considere descansar usando json. Pero recuerde, json es una notación inferior para especificar datos generales, en comparación con xml.

Ricardo
fuente
1
¿Por qué JSON es inferior a xml?
Malky.Kid
@ Malky.Kid: Por supuesto, siempre se puede encontrar una manera de representar cualquier documento XML como JSON, por lo que JSON no es inferior en lo que puede expresar con él. Pero XML, por un lado, ofrece más capacidades sintácticas para expresar metadatos fuera de la caja (esquema, información de tipo, comentarios, espacios de nombres, instrucciones de procesamiento, incluso la codificación de caracteres que se utilizará) sin que todos tengan que inventar y decidir un esquema de datos hacer estas cosas por ellos (como lo es con JSON), así que en ese sentido creo que es justo decir que ofrece capacidades superiores que JSON.
stakx