Escribiendo un cliente para una API RESTful (hipermedia)

Question

He estado leyendo sobre las API RESTful 'reales' durante unos días, y creo que Estoy cerca de pensar en qué se trata.

Pero una de las cosas que me tropiezo con es que no puedo ni siquiera comenzar a imaginar cómo se podría escribir un cliente para un 'real' hipermedia API:

1. mayoría de los ejemplos I' he leído sobre navegadores y arañas, pero eso no es especialmente útil: uno es dirigido por humanos e "inteligente", el otro es tonto y "aleatorio". Tal como están las cosas, tengo la impresión de que necesitarías aprender IA para que un cliente trabaje.

2. Una cosa que no me queda clara es cómo el cliente sabe qué verbo usar en un enlace determinado. ¿Está eso implícito en el tipo 'rel' del uri? La alternativa (leyendo here) parece estar usando xhtml y teniendo un cliente que puede analizar y publicar formularios.

3. ¿Cuán probable es que un enlace cambie, pero no la ruta al enlace? En la mayoría de los ejemplos que ven a su alrededor, la ruta y el enlace son los mismos:

por ejemplo. si quiero configurar un cliente que me va a traer de vuelta a la lista de los pasteles de Toni Cake Shop:

http://tonis.com 
{ link: { type : "cakes" ; uri : "http://tonis.com/cakes" } } 

¿Qué pasa cuando se hace de Toni Toni Food Shop, y el vínculo se convierte en http://tonis.com/desserts/cakes?

¿Conservamos el enlace inicial cakes en la raíz, para la compatibilidad inversa? Y si no, ¿cómo hacemos una 'redirección' para el pobre agente al que le han dicho "ir a la raíz, buscar pasteles"?

¿Qué me estoy perdiendo?

Answer 1

@Benjol

Hay que evitar a los clientes contra determinados URI de programar. Cuando describes un enlace, la importancia principal tiene su significado y no el URI en sí mismo. Puede cambiar el URI en cualquier momento, aunque esto no debe romper su cliente.

que cambiaría su ejemplo de esta manera:

{"link": { 
    "rel": "collection http://relations.your-service.com/cakes", 
    "href": "http://tonis.com/cakes", 
    "title": "List of cakes", 
    "type": "application/vnd.yourformat+json" 
}} 

si hay un cliente que consume su servicio, se tiene que entender:

• estructura de enlace en sí
• relaciones de enlace (en este caso "colección" que es RFC y "http://relations.your-service.com/cakes" que es su dominio relación de enlace específico)

En este caso, el cliente puede desreferenciar la dirección especificada por el atributo "href" y mostrar la lista de tortas. Más tarde, si cambia el cliente de URI del proveedor de la lista de tartas, seguirá funcionando, esto implica que el cliente todavía entiende la semántica de su tipo de medio.

P.S.

• Ver atributos de enlace registrada relación:
• Web de RFC Vinculación: http://tools.ietf.org/html/rfc5988

Answer 2

Ok, tampoco soy un experto en REST, he estado leyendo muchas cosas relacionadas últimamente, así que lo que voy a escribir no es mi experiencia u opinión, sino más bien un resumen de lo que leo, especialmente, el libro REST In Practice.

En primer lugar, no puede evitar tener un acuerdo inicial entre el cliente y el servidor, el objetivo de REST es hacer que se pongan de acuerdo sobre el mínimo de cosas que son relevantes para ambos y dejar que cada parte sobre sus propias cosas ellos mismos. Por ejemplo, al cliente no le debe importar el diseño de los enlaces o cómo se almacenan los datos en el servidor, y el servidor no debería preocuparse por el estado del cliente. Lo que acordaron por adelantado (es decir, antes de que comience la interacción) es lo que los autores del libro mencionado anteriormente denominan "Protocolo de aplicación de dominio" (DAP).

Lo importante de DAP es que es con estado, aunque HTTP no lo es (ya que cualquier interacción cliente-servicio tiene estado, al menos, comienzo y fin). Este estado se puede describir en términos de "Lo que un cliente puede/puede/se espera que haga a continuación": "Empecé a usar el servicio, ¿ahora qué? Ok, puedo buscar elementos Buscar este ítem, ¿qué viene? Ok , Puedo ordenar esto y lo otro ... etc. "

La definición de Hypermedia content-type es capaz de manejar tanto el intercambio de datos como el estado de interacción. Como ya mencioné, el estado se describe en términos de posibles acciones, y como viene de "Recurso" en REST, todas las acciones se describen en términos de recursos accesibles. Supongo que has visto el acrónimo "HATEOAS (Hipermedia como el motor del estado de la aplicación), así que aparentemente es eso.

Por lo tanto, para interactuar con el servicio, un cliente utiliza un formato hipermedia que ambos entienden, que puede ser estándar, de cosecha propia o una combinación de esos (por ejemplo, basado en XML/XHTML). Además de eso, también deben compartir el protocolo, que probablemente sea HTTP, pero como se omiten algunos detalles del estándar, debe haber algunos modismos de su uso, como "Usar POST para crear un recurso y PUT para actualizar". . Además, dicho protocolo incluiría los puntos de entrada del servicio (nuevamente, en términos de recursos accesibles).

Estos tres aspectos definen completamente el protocolo de dominio. En particular, se supone que un cliente no debe conocer ningún enlace interno antes de comenzar a usar el servicio o recordarlo una vez que se complete la interacción. Como resultado, cualquier cambio en la navegación interna, como cambiar el nombre de /cakes a /f5d96b5c, no afectará al cliente tan pronto como cumpla con el acuerdo inicial y entre a la tienda a través de la puerta de entrada.

Answer 3

Después de ver este video de una charla byJon Moore que tenía mucho mejor comprensión de apis Hypermed http://oredev.org/2010/sessions/hypermedia-apis