Je faisais un peu de lecture sur le REPOS ce matin et je suis tombé sur le HATEOAS principe ("hypermédia comme le moteur de l'état de l'application").
Citant le RESTE page de Wikipédia:
Les Clients à faire les transitions de l'état uniquement à travers des actions qui sont identifiés de manière dynamique au sein de l'hypermédia par le serveur (par exemple, par des liens hypertextes à l'intérieur de l'hypertexte). Sauf pour de simples fixe de points d'entrée pour l'application, un client n'a pas supposer que des actions particulières seront disponibles pour n'importe quel particulier de ressources au-delà de celles décrites dans les représentations précédemment reçu du serveur.
...si le moteur de l'état de l'application (et donc de l'API) n'est pas animé par l'hypertexte, alors il ne peut pas être tranquille et ne peut pas être une API REST. Période.
J'ai lu ce que: Le client ne peut demander que des modifications de l'état sur la base des actions disponibles à partir du corps de la réponse du serveur (l'hypertexte).
Dans un HTML monde, cela fait beaucoup de sens. Le client doit seulement être en mesure de demander des modifications de l'état (les nouvelles actions/pages), basé sur les liens mis à disposition par l'intermédiaire de l'hypertexte (HTML).
Lorsque la ressource est représentée par d'autres moyens, tels que JSON, XML, YAML, etc. Ce n'est pas si évident.
Prenons un exemple de "REPOS" API JSON:
J'ai créer une nouvelle ressource (un commentaire par exemple) par l'envoi d'une requête POST
/comments.json? # with params...
Le serveur répond avec:
# Headers
HTTP/1.1 201 Created
Location: http://example.com/comments/3
Content-Type: application/json; charset=utf-8
... Etc.
# Body
{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}
Je sais que je peux maintenant accéder à ce commentaire à l'URI de retourné dans l'en-tête: http://example.com/comments/3.json
Lorsque je visite http://example.com/comments/3.json je vois:
{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}
Supposons que l'API de la documentation me dit que je peux supprimer ce commentaire par l'envoi d'une demande de SUPPRESSION à la même URI. C'est assez commun parmi les "REPOS" Api.
Cependant:
La réponse du serveur à l' GET http://example.com/comments/3.json ne me dit rien au sujet d'être en mesure de supprimer le commentaire par l'envoi d'une demande de SUPPRESSION. Tous il me montre la ressource.
Que je peux aussi SUPPRIMER un commentaire avec la même URL est quelque chose que le client sait par out-of-band de l'information (la documentation) et n'est pas découvert et piloté par la réponse du serveur.
Ici, le client est en supposant que la SUPPRESSION de l'action (et d'autres) sont disponibles pour cette ressource, et cette information n'a pas été précédemment reçu du serveur.
Ai-je mal compris HATEOAS ou suis-je en droit de dire qu'une API correspondant à la description ci-dessus ne serait pas, au sens strict, être une API REST?
Je suis conscient adhère à 100% RESTE n'est pas toujours possible, ni la manière la plus pragmatique pour aller. J'ai posté cette question purement pour satisfaire ma propre curiosité à propos de la théorie derrière le REPOS, et non pas pour obtenir des conseils sur le monde réel des meilleures pratiques.
