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

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.

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.

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.

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.

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

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.