¿Existen estrategias para descubrir servicios REST usando HATEOAS?

10

Al crear un servicio REST con la restricción HATEOAS , es muy fácil anunciar la existencia de recursos a través de enlaces. Llegas GETa la raíz de mi sitio y yo respondo con el documento raíz que enumera todos los recursos de primer nivel:

{
    users: { href: "/users" }
    questions { href: "/questions" }
}

Los clientes que entienden cómo leer estos hrefvalores podrían realizar GETsolicitudes sobre ellos y descubrir todos los recursos actuales disponibles en la aplicación.

Esto funciona bien para escenarios de búsqueda básicos, pero no indica si un recurso es consultable. Por ejemplo, puede ser razonable realizar:

GET /users?surname=Smith

¿Hay algún formato que pueda expresar esta capacidad de consulta con suficiente información para que un cliente pueda formar una consulta coherente sin el conocimiento previo necesario del recurso?

Además, ¿hay alguna forma de expresar que un cliente puede realizar una POSTubicación determinada con una ubicación esperada? Por ejemplo, se podría esperar que un cliente realice lo siguiente para crear un nuevo recurso de preguntas:

POST /questions

{
    title: "Are there strategies for discovering REST services using HATEOAS?",
    body: "When building a REST service with the HATEOAS constraint, it's very..."
}

Cuando usamos HTML como formato para el consumo humano, podemos expresar mucho de esto mediante el uso de formularios y mensajes escritos para permitir que un humano descubra las operaciones que puede realizar en un servicio.

¿Hay formatos que sean capaces de cosas similares para los clientes?

design rest hateoas

— Paul Turner
fuente

2

El problema con el descubrimiento de un servicio REST se ha discutido y respondido aquí: stackoverflow.com/questions/9101494/... La solución más simple es usar una plantilla XHTML con un formulario que no solo informe sobre el método que puede usar sino también estructura de objeto que se enviará a través de los elementos del formulario (entrada, selección, etc.). Los clientes solo necesitan tener un analizador XML para encontrar lo que necesitan. Otra forma es con las plantillas de URL, pero solo ayudan con los recursos que toman cadenas de consulta.

— Spoike

En cuanto a los tipos de contenido; eso se resuelve con negociación de contenido que se realiza en encabezados HTTP. Si el servidor no puede servir un tipo de contenido solicitado, debería devolver un error HTTP (como 300 o 406) que indique qué tipos de contenido puede devolver.

— Spoike

1

¿Cómo saber qué tipo de insumos son aceptables? Es decir, si su cliente no tiene conocimiento previo, ¿cómo definiría la semántica del "apellido"? Estás comenzando a entrar en el territorio de necesitar algo como OWL .

Creo que es más práctico esperar que sus clientes comprendan la semántica de los tipos mime conocidos; digamos, por ejemplo, "texto / vcard" para personas.

— Stephen J. Anderson
fuente

Creo que el uso del tipo de contenido es el camino a seguir; Podría cambiar fácilmente mi aplicación para usarla application/atomapp+xmly ponerla a disposición de todos los clientes que ya entienden este formato. Es probable que haya suficientes tipos de contenido bien conocidos para hacer de esta una solución práctica.

— Paul Turner

Creo que el comentario de @Spoike es un elegante enfoque REST-ian para la otra mitad del problema; incluso si el cliente sabe que (por ejemplo) un usuario está representado como una vCard, aún necesita saber qué subconjunto de propiedades del usuario están disponibles para buscar.

— Stephen J. Anderson

4

Puede publicar detalles sobre sus servicios a través de un "WADL"

http://en.wikipedia.org/wiki/Web_Application_Description_Language

Es opcional y no todos los backend REST technos lo admiten. Jersey, la implementación java "oficial" de jax-rs, lo admite, por ejemplo, puede generarse automáticamente para usted.

Sin embargo, es bastante raro verlo usado.

No sé de los grandes que lo usan. En general, tiene una página web que describe la API.

— deshacer
fuente

1

CXF es otra gran implementación Java JAX-RS que admite WADL, y ahora también está empezando a ver algunos consumidores WADL de terceros interesantes.

— Donal Fellows

0

Spring tiene algo de apoyo para esto, al igual que el resteasy.

— jiggy
fuente