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?


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

Respostas:


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.


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.


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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.