Je ne comprends pas les avantages d'HATEOAS pour les API destinées à être utilisées par des programmes (par opposition aux humains qui parcourent directement votre API). Bien sûr, le client n'est pas lié à un schéma d'URL, mais il est lié à un schéma de données, ce qui est la même chose dans mon esprit.
Par exemple, supposons que je souhaite afficher un article sur une commande, supposons que j'ai déjà découvert ou connu l'URL de la commande.
HATEOAS:
order = get(orderURL);
item = get(order.itemURL[5]);
non HATEOAS:
order = get(orderURL);
item = get(getItemURL(order,5));
Dans le premier modèle, je dois savoir que l'objet de commande a un champ itemURL. Dans le deuxième modèle, je dois savoir comment construire une URL d'élément. Dans les deux cas, je dois "savoir" quelque chose à l'avance, alors que fait HATEOAS pour moi?
web-development
rest
Rythme
la source
la source
get(orderURL);devrait vous le direthe fact that the order object has an itemURL field.Réponses:
Une différence est que le schéma est, espérons-le, une norme, ou du moins peut être réutilisé par d'autres.
Par exemple, supposons que vous utilisez l'API Twitter et que vous souhaitez également prendre en charge StatusNet (ou à la place). Puisqu'ils utilisent le même modèle de données que Twitter, si l'API suit HATEOAS, il vous suffit maintenant de changer l'URL principale. Si ce n'est pas le cas, vous devez maintenant modifier chaque URL unique à partir du code.
Bien sûr, si vous devez de toute façon modifier le code pour mettre l'URL du point d'entrée du service, cela peut ne pas sembler si utile. Cela brille vraiment si cette URL est insérée dynamiquement; par exemple, si vous construisiez un service comme Twillio, qui interagirait avec la propre API de l'utilisateur.
la source
API explorable: Cela peut sembler trivial mais ne sous-estimez pas la puissance d'une API explorable. La possibilité de parcourir les données permet aux développeurs clients de créer beaucoup plus facilement un modèle mental de l'API et de ses structures de données.
Documentation en ligne: L'utilisation d'URL en tant que relations de lien peut diriger les développeurs clients vers la documentation.
Logique client simple: Un client qui suit simplement les URL au lieu de les construire lui-même, devrait être plus facile à implémenter et à maintenir.
Le serveur s'approprie les structures URL: l'utilisation d'hypermédia supprime la connaissance codée en dur du client des structures URL utilisées par le serveur.
Déchargement de contenu vers d'autres services: Hypermedia est nécessaire lors du déchargement de contenu vers d'autres serveurs (un CDN par exemple).
Gestion des versions avec des liens: Hypermedia aide à la gestion des versions des API.
Implémentations multiples du même service: Hypermedia est une nécessité lorsqu'il existe plusieurs implémentations du même service (et qu'un client doit accéder à plusieurs d'entre elles).
Vous pouvez trouver une explication détaillée de ces puces ici: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html
la source