servicios - ¿Qué tan útil/importante es REST HATEOAS(nivel de madurez 3)?
restful java que es (4)
Me estoy involucrando en un proyecto en el que algunos miembros del equipo senior creen que una API REST debe ser compatible con HATEOAS e implementar todos los niveles de madurez de Richardson ( http://martinfowler.com/articles/richardsonMaturityModel.html ).
AFAIK la mayoría de las implementaciones de REST no son compatibles con HATEOAS y debería haber una buena razón por la que más personas no lo están haciendo. Puedo pensar en razones como la complejidad añadida, la falta de marcos (lados del servidor y del cliente), la preocupación por el rendimiento y ...
¿Qué piensas? ¿Has tenido alguna experiencia con HATEOAS en un proyecto del mundo real?
Creo que una API se puede llamar RESTful, incluso si el lado del cliente de la aplicación no sigue los principios de HATEOAS. En la mayoría de los casos, el cliente debe violar HATEOAS para satisfacer los requisitos de usabilidad. Dejame explicar.
HATEOAS no solo impone una restricción en el lado del servidor de la aplicación, sino también en el lado del cliente. El cliente no debe suponer que un recurso tiene una estructura específica más allá de la estructura definida por el tipo de medio. El servidor debería ofrecer una API que admita dicho cliente.
Ahora, supongamos que hemos logrado esto. El lado del cliente de la aplicación ahora es muy genérico, pero lo más probable es que la experiencia del usuario sea mala, porque sin ningún conocimiento de la semántica de los recursos, la presentación de los recursos no se puede adaptar para reflejar esa semántica. Si el recurso ''coche'' y el recurso ''casa'' tienen el mismo tipo de medio (por ejemplo, aplicación / json), entonces se presentarán al usuario de la misma manera, por ejemplo como una tabla de propiedades (pares nombre / valor).
Pero está bien, nuestra API es realmente RESTful.
Ahora, supongamos que construimos una segunda aplicación de cliente sobre esta API. Este segundo cliente viola las ideas de HATEOAS y tiene información codificada sobre los recursos. Muestra un automóvil y una casa de diferentes maneras.
¿La API todavía se puede llamar RESTful? Creo que si. No es culpa de la API que uno de sus clientes haya violado HATEOAS.
Aconsejo construir API RESTful, es decir, API para las cuales se puede implementar un cliente genérico en teoría , pero en la mayoría de los casos, se necesita información codificada sobre los recursos en su cliente para satisfacer los requisitos. Aún así, intente codificar lo menos posible, para reducir las dependencias entre el cliente y el servidor.
He incluido una sección sobre HATEOAS en mi patrón de implementación de REST llamado JAREST .
He usado HATEOAS en algunos proyectos reales, pero con una interpretación diferente a la de Richardson. Si eso es lo que quieren tus jefes, entonces supongo que deberías hacerlo. Considero que HATEOAS significa que sus recursos deben incluir un tipo de documento HTML, hipervínculos a recursos relacionados y formularios HTML para exponer la funcionalidad de verbos que no sean GET. (Aquí es cuando el tipo Aceptar es texto / html; otros tipos de contenido no requieren estos extras.) No sé de dónde viene la creencia de que todos los recursos REST de toda la aplicación deben pegarse. Una aplicación de red debe contener múltiples recursos que pueden o no estar directamente relacionados. O por qué se cree que XML, JSON y otros tipos deben seguir esto. (HATEOAS es específico de HTML.)
Nadie en la comunidad REST dice que RESTO es fácil. HATEOAS es solo uno de los aspectos que agrega dificultad a una arquitectura REST.
La gente no hace HATEOAS por todas las razones que sugiere: es difícil. Agrega complejidad tanto al lado del servidor como al cliente (si realmente quiere beneficiarse de él).
SIN EMBARGO, miles de millones de personas experimentan los beneficios de REST hoy. ¿Sabes cuál es la URL de "pago y envío" en Amazon? Yo no. Sin embargo, puedo pagar todos los días. ¿Ha cambiado esa URL? No sé, no me importa.
¿Sabes que te importa? Cualquiera que haya escrito una pantalla eliminó el cliente automatizado de Amazon. Alguien que probablemente olfateó minuciosamente el tráfico web, leyó páginas HTML, etc. para encontrar los enlaces a los que llamar cuando y con qué cargas.
Y tan pronto como Amazon cambió sus procesos internos y su estructura de URL, esos clientes con código fijo fallaron, porque los enlaces se rompieron.
Sin embargo, los navegantes web ocasionales pudieron comprar todo el día sin problemas.
Eso es REST en acción, solo lo aumenta el ser humano que es capaz de interpretar e intuir la interfaz basada en texto, reconocer un pequeño gráfico con un carrito de compras y descubrir qué significa eso en realidad.
La mayoría de las personas que escriben software no hacen eso. A la mayoría de las personas que escriben clientes automáticos no les importa. A la mayoría de las personas les resulta más fácil arreglar a sus clientes cuando se rompen que diseñar la aplicación para que no se rompan en primer lugar. La mayoría de la gente simplemente no tiene suficientes clientes donde importa.
Si está escribiendo una API interna para comunicarse entre dos sistemas con soporte técnico experto y TI en ambos lados del tráfico, que pueden comunicar los cambios de manera rápida, confiable y con un cronograma de cambios, entonces REST no le compra nada. No lo necesita, su aplicación no es lo suficientemente grande, y no es lo suficientemente larga como para importar.
Los grandes sitios con grandes bases de usuarios tienen este problema. No pueden simplemente pedirles a las personas que cambien su código de cliente por capricho cuando interactúan con sus sistemas. El cronograma de desarrollo de servidores no es el mismo que el cronograma de desarrollo del cliente. Los cambios abruptos en la API son simplemente inaceptables para todos los involucrados, ya que interrumpen el tráfico y las operaciones en ambos lados.
Por lo tanto, una operación de este tipo probablemente se beneficiaría de HATEOAS, ya que es más fácil de realizar la versión, más fácil para los clientes más antiguos migrar, más fácil de ser compatible hacia atrás que no.
Un cliente que delega gran parte de su flujo de trabajo en el servidor y actúa sobre los resultados es mucho más sólido para los cambios del servidor que un cliente que no lo hace.
Pero la mayoría de la gente no necesita esa flexibilidad. Están escribiendo código de servidor para 2 o 3 departamentos, todo es de uso interno. Si se rompe, lo arreglan, y lo tienen en cuenta en sus operaciones normales.
La flexibilidad, ya sea de REST o de cualquier otra cosa, genera complejidad. Si lo quiere simple y rápido, no lo hace flexible, simplemente "hágalo" y listo. A medida que agrega abstracciones y desreferenciaciones a los sistemas, las cosas se vuelven más difíciles, más placas de calderas, más código para probar.
Gran parte de REST falla el punto de "no lo va a necesitar". Hasta que, por supuesto, lo haces.
Si lo necesita, utilícelo y úselo como está diseñado. REST no está empujando cosas hacia adelante y hacia atrás a través de HTTP. Nunca lo ha sido, es un nivel mucho más alto que eso.
Pero cuando necesitas REST y usas REST, entonces HATEOAS es una necesidad. Es parte del paquete y una clave de lo que lo hace funcionar en absoluto.
Sí, he tenido alguna experiencia con hipermedia en API. Estos son algunos de los beneficios:
API explorable: puede sonar trivial, pero no subestimes el poder de una API explorable. La capacidad de navegar alrededor de los datos hace que sea mucho más fácil para los desarrolladores del cliente construir un modelo mental de la API y sus estructuras de datos.
Documentación en línea: el uso de URL como relaciones de enlace puede orientar a los desarrolladores de clientes hacia la documentación.
Lógica de cliente simple: un cliente que simplemente sigue las direcciones URL en lugar de construirlas por sí mismo, debería ser más fácil de implementar y mantener.
El servidor se apropia de las estructuras de URL: el uso de hipermedia elimina el conocimiento del cliente de las estructuras de URL utilizadas por el servidor.
Desactivar la carga de contenido a otros servicios: Hypermedia es necesario cuando descarga contenido a otros servidores (por ejemplo, un CDN).
Versiones con enlaces: Hypermedia ayuda al control de versiones de las API.
Múltiples implementaciones del mismo servicio: Hypermedia es una necesidad cuando existen múltiples implementaciones del mismo servicio (y un cliente necesita acceder a más de uno de ellos).
Puede encontrar una explicación detallada de estos puntos aquí: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html
(hay una pregunta similar aquí: https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas donde he dado la misma explicación)