api - specifically - Ejemplos reales para HATEOAS(REST-architecture)
spring hal (5)
¿No es el RESTfulness de Sun Cloud API realmente abordado 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 su lugar, permita que los servidores instruyan a los clientes sobre cómo construir URIs apropiados, como se hace en formularios HTML y plantillas 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 a datos orientado al acoplamiento funcional de RPC].
Ejemplo 1 Nombres de recursos fijos en una heiraquía definida:
De Sun Cloud API: "... la representación de un VDC incluirá representaciones de los Clusters que lo habitan, que a su vez incluyen representaciones de las VM dentro de cada clúster".
Ejemplo 2 de información fuera de banda, como un estándar específico de dominio:
Debe tener los contenidos 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.
como todos habrán notado, hay muchas REST-API falsas / rudimentarias en la naturaleza (que implementan una HTTP-API y la llaman REST sin seguir el requisito de hipertexto-como-motor-de-aplicación-estado, que llevó a la famosa diatriba de Roy T. Fielding , el hombre que especificó por primera vez el paradigma REST).
No he podido encontrar ejemplos prácticos de una implementación de REST realmente impulsada por hipertexto junto con las definiciones asociadas de tipos de medios específicos de la aplicación para las transiciones de estado.
¿Hay algún ejemplo accesible al público de tales implementaciones?
¿Qué hay de la API Sun Cloud ? De la introducción:
La API no presupone ninguna estructura particular en el espacio de URI. El punto de partida es un URI, proporcionado 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, implementación e inicio de máquinas virtuales).
La backstory también puede ser útil.
Me di cuenta de que esto fue preguntado hace un tiempo, pero probé a demostrar un flujo API REST "adecuado" para un ejemplo simple. Traté de seguir las reglas de Roy para REST, quizás podría ayudar: Ejemplo de API usando REST
No es una implementación en el sentido de ejecutar código, pero realmente me gusta el artículo " Cómo conseguir 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.
Netflix tiene una API REST basada en HATEOAS que incluye enlaces como parte de los recursos.