¿Es REST y HATEOAS una buena arquitectura para servicios web?

14

Si entiendo correctamente, REST fue formalizado por Roy Fielding como un 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. En este punto, la web ya había demostrado ser un enorme sistema de hipertexto distribuido exitoso, por lo que este tipo valida a 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 realmente alguna razón para pensar que REST es una arquitectura deseable para este dominio? Más específicamente, ¿existe alguna evidencia que indique que HATEOAS es un principio de diseño beneficioso para la comunicación máquina a máquina?

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

    
pregunta JacquesB 29.04.2017 - 13:20
fuente

5 respuestas

14
  

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

Eso lo subestima un poco, me parece. REST es, después de todo, una enumeración del estilo arquitectónico que Fielding estaba usando como arquitecto principal de especificación de HTTP / 1.1 .

  

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

"Depende". HATEOAS forma parte de la interfaz uniforme de REST.

  

Al aplicar el principio de generalidad de la 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 desacopladas de los servicios que brindan, lo que fomenta la capacidad de evolución independiente. Sin embargo, la compensación es que una interfaz uniforme degrada la eficiencia, ya que la información se transfiere en una forma estandarizada en lugar de una que es específica a las necesidades de una aplicación. La interfaz REST está diseñada para ser eficiente para la transferencia de datos de hipermedia de grano grande, 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.

Así que pensemos por un momento lo que esto significa. Cuando tengo problemas con mi enrutador inalámbrico, puedo comunicarme con él usando el mismo navegador que utilizo para enviar respuestas a stackexchange. En particular, no importa qué navegador estoy usando, o si mi navegador tiene algunas actualizaciones detrás (o más adelante) 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.

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á diseñado para aplicaciones basadas en 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 se eligieron para las propiedades que inducen; Si esas propiedades no son valiosas para su caso de uso, entonces absolutamente debería considerar eliminar las restricciones correspondientes.

Donde la máquina se torna difícil es que se ha perdido la capacidad del ser humano para igualar la semántica proporcionada por las representaciones. Los clientes pueden subsistir conociendo solo los tipos de medios, pero normalmente tenemos un ser humano mirando las señales semánticas para obtener un 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 propio entendimiento del significado para elegir las acciones correctas a tomar.

Pero es trabajo; debe invertir en el desarrollo de representaciones fáciles de usar de sus recursos y asegurarse de que esas representaciones sigan siendo compatibles hacia adelante y hacia atrás, para que los clientes puedan desarrollarse de manera independiente.

Cuando una sola organización controla tanto al cliente como al servidor, los beneficios de esta independencia son mucho más pequeños, en cuyo caso la restricción puede no ser una opción arquitectónica adecuada.

    
respondido por el VoiceOfUnreason 29.04.2017 - 16:39
fuente
4

No, 'REST total' no es tan bueno.

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

Pero tienes que 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, identificaciones de conversación y estado.

Poner en marcha estas cosas y luego explicarlas a los consumidores de la API fue una tarea difícil. "¿por qué no acabo de hacer un GET con el ID 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 una molestia y acabarías con enormes archivos txt que consistían principalmente en <MyLongObjectName> . Así que 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 impide que se descargue una API utilizable, que es lo suficientemente simple como para que los consumidores "solo la obtengan" y la utilicen sin un 6 Mes en proceso de embarque.

    
respondido por el Ewan 30.04.2017 - 08:20
fuente
2

Es de notar 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 luego se conocerá 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 (HTTP / 1.0) [19] y diseñar las extensiones para los nuevos estándares de HTTP / 1.1 [42] y los Identificadores de recursos uniformes (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 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 los defectos en la arquitectura preexistente podrían ser identificado y las extensiones validadas antes de la implementación .

REST y 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 la red al mismo tiempo que maximiza la independencia y la escalabilidad de las implementaciones de componentes . Esto se logra al colocar restricciones en la semántica del conector donde otros estilos se han enfocado en la semántica de los componentes. REST permite el almacenamiento en caché y la reutilización de interacciones, la sustitución dinámica de componentes y el procesamiento de acciones por parte de intermediarios , lo que satisface 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 adecuados para todos los problemas:

  

Del mismo modo, las extensiones propuestas pueden compararse con REST para ver si encajan dentro de 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 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 limitaciones de la web, en realidad deberían haber sido 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 de larga duración; para estos problemas, las restricciones REST son solo una camisa de fuerza.

  

¿Pero hay realmente alguna razón para pensar que REST es una arquitectura deseable para este dominio? Más específicamente, ¿hay alguna evidencia que diga que HATEOAS es 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 de problemas no tienen todos los requisitos de la Web y no necesitan obedecer todas las restricciones de REST para funcionar bien. Esta es la razón por la cual hay muchas arquitecturas exitosas que funcionan bien solo aplicando algunas partes de REST pero no las otras. HATEOAS y Uniform Interface, por ejemplo, son principios que a menudo se omiten las API que no necesitan cruzar los límites de la organización y los sistemas que tienen un período de amortización relativamente corto.

    
respondido por el Lie Ryan 30.04.2017 - 15:00
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 una 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 una API RESTful. En realidad, cuando las personas enfrentaban restricciones REST, eliminaron algunas de estas restricciones porque no era necesario o no se obtenía ningún beneficio para que aplicaran todas las restricciones.

Como mencionó, HATEOAS es útil cuando el cliente es un navegador web. Cuando el cliente es una aplicación móvil, tal vez 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, para dar un ejemplo, el equipo de la aplicación móvil y el equipo de back-end acordaron eliminar esa restricción. Y eso tiene sentido porque ambos equipos no están tan débilmente acoplados porque trabajan para la misma empresa.

REST en AEM

    
respondido por el imel96 24.05.2017 - 18:16
fuente
0

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

    
respondido por el Richard 02.05.2017 - 02:51
fuente

Lea otras preguntas en las etiquetas