REST Implementación del cliente Abrazar la restricción de HATEOAS?

Question

¿Alguien sabe de una implementación de un cliente REST que incluye la restricción de Hypermedia as the Engine of Application State (HATEOAS)?

El Sun Cloud API parece ser un buen candidato, a juzgar por la forma en que está documentado y a statement by the author en el sentido de que las implementaciones de Ruby, Java y Python estaban en proceso. Pero hasta ahora no he encontrado rastro del código.

Estoy buscando algo, incluso una implementación parcial sería útil.

Answer 1

El principio de diseño de HATEOAS (REST también es un conjunto de principios de diseño) significa que cada recurso debe tener como máximo una sola URL fija.

Todo lo demás relacionado debe ser reconocible dinámicamente desde esa URL a través de enlaces "hipermedia".

simplemente empecé un stub Wikipedia here

Answer 2

Restfulie es una infraestructura Ruby #, Java y C, que tiene por objeto permitir la construcción de los clientes y servidores que emplean HATEOAS. No lo he usado, pero se ve interesante.

Aquí hay un código de ejemplo de their java project:

Order order = new Order(); 

// place the order 
order = service("http://www.caelum.com.br/order").post(order); 

// cancels it 
resource(order).getTransition("cancel").execute(); 

Una vez más, no estoy seguro exactamente lo que esto hace, o lo bien que funciona en la práctica, pero sí parece intrigante.

Answer 3

Rich,

estoy trabajando en un marco de cliente de descanso para Jersey en este momento. Una vez que el diseño inicial se estabilice un poco, se agregará a la base del código de Jersey y, después de pasar por la comunidad para su revisión, finalmente debería tener la forma del marco del lado del cliente de JAX-RS.

Ha habido una animada discusión en la lista de usuarios de Jersey recientemente sobre todo lo RESTful. https://jersey.dev.java.net/servlets/SummarizeList?listName=users

En un plazo de dos semanas, el código se hará público la primera vez que la gente experimente.

Ene

Answer 4

El problema con REST HTTP y HATEOAS es que no existe un enfoque común para la especificación de enlaces por lo que es difícil de seguir enlaces, ya que su estructura puede cambiar de un proveedor de servicio a otro. Algunos usarían <link href="..." /> otros usarían la estructura propietaria para de enlaces ex. <book href="..." />. No es como en HTML o átomo donde el enlace es parte de un estándar definido.

Un cliente no puede saber lo que es un enlace en su representación es que no sabe el tipo de material a menos que haya una representación estándar o convencional de un enlace

Answer 5

La primera cosa que usted debe mirar es el navegador web común. Es el estándar para un cliente que adopta HATEOAS (al menos hasta cierto punto).

Así es como funciona Hypermedia.Es tan simple que es casi doloroso:

1. apunta su navegador a http://pigs-are-cool.org/
2. el navegador carga la página HTML, imágenes, CSS y así sucesivamente.
   • En este punto, la aplicación (su experiencia de navegación) está en un URI específico.
   • El navegador está mostrando el contenido de ese URI
3. ves un enlace en la aplicación
4. hacer clic en el enlace
5. el navegador sigue el enlace
   • en este punto, la la aplicación está en un URI diferente
   • El navegador muestra el contenido del nuevo URI

Ahora, para una breve explicación de cómo los dos términos se refieren a la experiencia de navegación web:

• Hipermedia = páginas HTML con los enlaces incorporados
• estado de la aplicación = Lo que están viendo en el navegador en cualquier punto en el tiempo.

Así HATEOAS describe realmente lo que sucede en un navegador web cuando se pasa de la página web a la página web:

páginas HTML con enlaces incorporados unidad lo que se ve en el navegador en cualquier punto time

El término HATEOAS es solo una abstracción de esta experiencia de navegación.

Otros ejemplos de aplicaciones de cliente REST incluyen:

• RSS y alimentar a los lectores. Atraviesan los enlaces que les dan los usuarios
• La mayoría de los clientes del blog AtomPub. Necesitan simplemente un URI para un documento de servicios, y a partir de allí descubren dónde subir imágenes y publicaciones de blogs, buscar, etc.
• Probablemente Google Gadgets (y similares), pero no son más que navegadores con una apariencia diferente.
• Los rastreadores web también son clientes RESTful, pero son un nicho de mercado.

Algunas características del software de cliente REST:

• El cliente trabaja con con cualquier servidor, dado que se ceba con un poco de URI y el servidor responde con un resultado esperado (por ejemplo, para un cliente de blog de átomo , un documento de servicios de Atom).
• El cliente no sabe nada sobre cómo el servidor diseña sus URI distintas de lo que puede averiguar en tiempo de ejecución
• El cliente sabe lo suficiente como tipos de medios y rel de entender lo que el servidor está diciendo (por ejemplo, Atom o RSS)
• El cliente usa enlaces incrustados para buscar otros recursos; algunos de forma automática (como <img src=) algunos de forma manual (como <a href=).

Muy a menudo son manejadas por un usuario y pueden denominarse correctamente "agentes de usuario", excepto, digamos, GoogleBot.

Answer 6

Spring Framework's RestTemplate se puede utilizar para lograr el propósito. Compruebe esto article para más detalles.