Existe-t-il des stratégies pour découvrir les services REST à l'aide de HATEOAS?

10

Lors de la création d'un service REST avec la contrainte HATEOAS , il est très facile d'annoncer l'existence de ressources via la liaison. Vous faites un GETà la racine de mon site et je réponds avec le document racine listant toutes les ressources de premier niveau:

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

Les clients qui comprennent comment lire ces hrefvaleurs pourraient effectuer des GETrequêtes sur celles-ci et découvrir toutes les ressources actuelles disponibles dans l'application.

Cela fonctionne bien pour les scénarios de recherche de base, mais n'indique pas si une ressource peut être interrogée. Par exemple, il peut être raisonnable d'effectuer:

GET /users?surname=Smith

Existe-t-il des formats qui pourraient exprimer cette capacité de requête avec suffisamment d'informations pour qu'un client puisse former une requête cohérente sans connaissance préalable de la ressource?

De plus, existe-t-il un moyen d'exprimer qu'un client est autorisé à effectuer un POSTà un emplacement donné avec un emplacement attendu. Par exemple, on peut s'attendre à ce qu'un client effectue les opérations suivantes pour créer une nouvelle ressource de questions:

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

Lorsque vous utilisez HTML comme format pour la consommation humaine, nous pouvons exprimer beaucoup de cela en utilisant des formulaires et des invites écrites pour permettre à un humain de découvrir les opérations qu'il est autorisé à effectuer sur un service.

Existe-t-il des formats capables de faire des choses similaires pour les clients?

design rest hateoas Paul Turner
la source
2
Le problème de la découverte d'un service REST a été discuté et répondu ici: stackoverflow.com/questions/9101494/… La solution la plus simple consiste à utiliser un modèle XHTML avec un formulaire qui non seulement indiquera la méthode que vous pouvez utiliser, mais aussi le structure d'objet à envoyer via les éléments du formulaire (saisie, sélection, etc.). Les clients n'ont besoin que d'un analyseur XML pour trouver ce dont ils ont besoin. Une autre façon consiste à utiliser les modèles d'URL, mais ils aident uniquement les ressources qui prennent des chaînes de requête.
Spoike
Concernant les types de contenu; qui est résolu avec la négociation de contenu qui se fait dans les en-têtes HTTP. Si le serveur ne peut pas servir un type de contenu demandé, il doit renvoyer une erreur HTTP (telle que 300 ou 406) indiquant les types de contenu qu'il peut renvoyer.
Spoike

Réponses:

1

Comment sauriez-vous quel type d'entrées sont acceptables? Autrement dit, si votre client n'a aucune connaissance préalable, comment définiriez-vous la sémantique du "nom de famille"? Vous commencez à avoir besoin de quelque chose comme OWL .

Je pense qu'il est plus pratique de s'attendre à ce que vos clients comprennent la sémantique des types MIME bien connus; dites, par exemple, "text / vcard" pour les gens.

Stephen J. Anderson
la source
Je pense que l'utilisation du type de contenu est la voie à suivre; Je pourrais facilement changer mon application pour l'utiliser application/atomapp+xmlet la rendre disponible pour tous les clients qui comprennent déjà ce format. Il existe probablement suffisamment de types de contenu bien connus pour en faire une solution pratique.
Paul Turner
Je pense que le commentaire de @Spoike est une élégante approche REST-ian de l'autre moitié du problème; même si le client sait que (par exemple) un utilisateur est représenté comme une vCard, il doit toujours savoir sur quel sous-ensemble des propriétés de l'utilisateur sont disponibles pour la recherche.
Stephen J. Anderson
4

Vous pouvez publier des détails sur vos services via un "WADL"

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

C'est facultatif et toutes les technos REST back-end ne le prennent pas en charge. Jersey, l'implémentation java "officielle" de jax-rs le supporte par exemple - il peut être généré automatiquement pour vous.

C'est assez rare cependant, de le voir utilisé.

Je n'en connais pas de grands qui l'utilisent. En général, vous avez une page Web décrivant l'API.

unludo
la source
1
CXF est une autre grande implémentation Java JAX-RS qui prend en charge WADL, et vous commencez également à voir quelques consommateurs WADL tiers intéressants.
Donal Fellows