Existem estratégias para descobrir serviços REST usando o HATEOAS?

10

Ao criar um serviço REST com a restrição HATEOAS , é muito fácil anunciar a existência de recursos por meio de vinculação. Você cria um GETna raiz do meu site e eu respondo com o documento raiz listando todos os recursos de primeira camada:

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

Os clientes que entenderem como ler esses hrefvalores poderão executar GETsolicitações sobre eles e descobrir todos os recursos atuais disponíveis no aplicativo.

Isso funciona bem para cenários de pesquisa básica, mas não indica se um recurso é consultável. Por exemplo, pode ser razoável executar:

GET /users?surname=Smith

Existem formatos que possam expressar essa capacidade de consulta com informações suficientes para que um cliente possa formar uma consulta coerente sem o conhecimento prévio necessário do recurso?

Além disso, existe alguma maneira de expressar que um cliente pode executar um POSTpara um determinado local com um local esperado. Por exemplo, pode-se esperar que um cliente execute o seguinte para criar um novo recurso de pergunta:

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..."
}

Ao usar o HTML como o formato para consumo humano, podemos expressar muito disso através do uso de formulários e de instruções por escrito para permitir que um ser humano descubra as operações que tem permissão para executar em um serviço.

Existem formatos capazes de coisas semelhantes para os clientes?

design rest hateoas

— Paul Turner
fonte

2

O problema com a descoberta de um serviço REST foi discutido e respondido aqui: stackoverflow.com/questions/9101494/… A solução mais simples é usar um modelo XHTML com um formulário que não apenas informe sobre o método que você pode usar, mas também o estrutura do objeto a ser enviada através dos elementos do formulário (entrada, seleção etc.). Os clientes precisam apenas de um analisador XML para encontrar o que precisam. Outra maneira é com os modelos de URL, mas eles apenas ajudam com recursos que usam cadeias de consulta.

— Spoike 8/07/2013

Em relação aos tipos de conteúdo; isso é resolvido com a negociação de conteúdo, que é feita nos cabeçalhos HTTP. Se o servidor não puder servir um tipo de conteúdo solicitado, ele retornará um erro HTTP (como 300 ou 406) informando quais tipos de conteúdo ele pode retornar.

— Spoike

1

Como você saberia que tipo de entradas são aceitáveis? Ou seja, se o seu cliente não tem conhecimento prévio, como você definiria a semântica do "sobrenome"? Você está começando a entrar no território de precisar de algo como OWL .

Eu acho que é mais prático esperar que seus clientes entendam a semântica dos tipos mime conhecidos; digamos, por exemplo, "text / vcard" para pessoas.

— Stephen J. Anderson
fonte

Eu acho que o uso do tipo de conteúdo é o caminho a percorrer; Eu poderia facilmente alterar meu aplicativo para uso application/atomapp+xmle disponibilizá-lo para todos os clientes que já entendem esse formato. Provavelmente existem tipos de conteúdo conhecidos suficientes para tornar essa uma solução prática.

— Paul Turner

Eu acho que o comentário de @Spoike é uma abordagem REST-ian elegante para a outra metade do problema; mesmo que o cliente saiba que (por exemplo) um usuário é representado como um vCard, ele ainda precisará saber em que subconjunto de propriedades do usuário estão disponíveis para pesquisa.

— Stephen J. Anderson

4

Você pode publicar detalhes de seus serviços através de uma "WADL"

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

É opcional e nem todos os technos REST de back-end suportam isso. Jersey, a implementação java "oficial" do jax-rs, oferece suporte, por exemplo - ela pode ser gerada automaticamente para você.

É bastante raro vê-lo usado.

Eu não sei dos grandes usando. Em geral, você tem uma página da web descrevendo a API.

— iludido
fonte

1

O CXF é outra grande implementação Java JAX-RS que suporta WADL, e você também está começando a ver alguns consumidores WADL de terceiros interessantes também.

— Donal Fellows

0

A primavera tem algum apoio para isso, assim como o descanso.

— jiggy
fonte