Ejemplos reales de HATEOAS (arquitectura REST) ​​[cerrado]

140

como todos habrán notado, hay muchas API REST falsas / rudimentarias en la naturaleza (que implementan una API HTTP y la llaman REST sin seguir el requisito de hipertexto como motor del estado de la aplicación, lo que llevó a al famoso discurso de Roy T. Fielding , el hombre que especificó por primera vez el paradigma REST).

No he podido encontrar ningún ejemplo práctico de una implementación REST verdaderamente impulsada por hipertexto junto con las definiciones de tipo de medios específicas de la aplicación asociada para las transiciones de estado.

¿Hay ejemplos de acceso público de tales implementaciones?

api rest hateoas pmf
fuente
3
Encuentro esto interesante ya que muchas personas afirman que REST es "fácil", pero el propio Fielding dice que aunque es una arquitectura simple, no es simple diseñar una aplicación con ella.
aehlke
3
por cierto, debería ser HATEOAS no HATEOS, el último no googlea bien.
David Roussel
1
restcookbook.com/Basics/hateoas
Ben
2
Paypal parece usarlo: developer.paypal.com/docs/integration/direct/…
Andrew Thaddeus Martin
¿Roy Fielding ha creado alguna vez una aplicación con HATEOAS?
systemovich

Respuestas:

102

No es una implementación en el sentido de ejecutar código, pero realmente me gusta el artículo " Cómo OBTENER una taza de café " en InfoQ. Describe el proceso de ordenar un café en Starbucks como un protocolo RESTful. Esto va más allá del típico artículo introductorio REST "todo es un recurso" y se centra en HATEOAS. Muy recomendable.

trendels
fuente
55
El libro "Descansa en la práctica" de Jim Webber, Sayas Parastatidis e Ian Robinson es bastante útil
DomreiRoam
2
El artículo está bien, pero desafortunadamente la API que describe no se adhiere estrictamente al principio HATEOAS porque no utiliza tipos de medios personalizados. ¿Cómo sabría el cliente cómo manipular (por ejemplo, deserializar, analizar, mostrar) cada recurso si todo es application / xml? Dependería de algunas formas no estándar de transmitir esta información, como la documentación destinada a ser leída por humanos.
ygormutti
21

¿Qué tal la API Sun Cloud ? De la introducción:

La API no presupone ninguna estructura particular en el espacio URI. El punto de partida es un URI, suministrado por el proveedor de servicios en la nube, que identifica la nube en sí. La representación de la nube contiene URI para los otros recursos en la nube, y también para las operaciones que se pueden realizar sobre ellos (por ejemplo, desplegar e iniciar máquinas virtuales).

La historia de fondo también podría ser útil.

Rich Apodaca
fuente
2
Es la historia de fondo lo que me hizo comenzar por el camino de los HATEAOS.
CyberFonic
3
todos los enlaces están muertos
Roeland Van Heddegem
"Lamentamos que el sitio kenai.com se haya cerrado".
Nick Rolando
@NickRolando, reemplacé el enlace.
Rich Apodaca
@RichApodaca, el enlace de la historia de fondo está muerto.
Vasantha Ganesh K
7

Netflix tiene una API REST basada en HATEOAS que incluye enlaces como parte de los recursos.

Will Sargent
fuente
1
y ahora el código de estado es 404.
naXa
1
El enlace @Will Sargent está roto, actualícelo.
Govi S
Lo sentimos, parece que Netflix lo eliminó y se fue con otra cosa.
Will Sargent
2
Las respuestas de solo enlace tienden a ser menos relevantes cuando dichos enlaces están muertos.
nyedidikeke
@nyedidikeke es un enlace pero una respuesta para este contexto, ¡solo necesitas arreglar el enlace editando la publicación!
Al-Mothafar
3

¿No se aborda la RESTfulness de Sun Cloud API en el cuarto punto de Roy:

Una API REST no debe definir nombres de recursos fijos o jerarquías (un acoplamiento obvio de cliente y servidor). Los servidores deben tener la libertad de controlar su propio espacio de nombres. En cambio, permita que los servidores instruyan a los clientes sobre cómo construir URI apropiados, como se hace en formularios HTML y plantillas de URI, definiendo esas instrucciones dentro de los tipos de medios y las relaciones de enlace. [La falla aquí implica que los clientes están asumiendo una estructura de recursos debido a la información fuera de banda, como un estándar específico de dominio, que es el equivalente orientado a datos para el acoplamiento funcional de RPC].

Ejemplo 1 Nombres de recursos fijos en una heirachy definida:

Desde la API de Sun Cloud: "... la representación de un VDC incluirá representaciones de los Clusters que lo habitan, que a su vez incluirán representaciones de las VM dentro de cada cluster".

Ejemplo 2 información fuera de banda, como un estándar específico de dominio:

Debe tener el contenido de la página wiki (información fuera de banda) para saber que el "mecanismo de comunicación de recursos" para el campo de recursos de la nube "uri" es GET.

Erizo
fuente
2
Tienes razón, eso es muy engañoso. Sin embargo, Roy está hablando de nombres de recursos en el espacio uri, no dentro del contenido del tipo de medio. Sun es libre de cambiar la uri que se utiliza para acceder a un clúster en cualquier momento. Obviamente, no puede cambiar el término "clúster" a "grupo" dentro de la representación sin crear una nueva versión del tipo de medio, pero puede cambiar el URI para que sea cualquier cosa.
Darrel Miller
44
Sabemos que la API de Sun usa HTTP como su interfaz uniforme, por lo que el cliente no necesita mirar la página wiki para saber que GET es un verbo válido para el recurso en la nube. Puede probarlo teniendo en cuenta que sabe que GET es un verbo seguro, o puede usar OPCIONES para determinar si está disponible.
Darrel Miller
3

Me di cuenta de que esto fue preguntado hace un tiempo, pero intenté demostrar un flujo de API REST "adecuado" para un ejemplo simple. Traté de seguir las reglas de Roy para REST, tal vez podría ayudar: Ejemplo de API usando REST

jeremyh
fuente