REST et URI Caching

Question

Si je comprends bien, en utilisant un conduit hypertexte RESTful service Web, un client n'est pas censé savoir quoi que ce soit à propos de la mise en page URI serveur, sauf pour un couple de points d'entrée bien connus. Ce système est censé permettre au serveur de contrôler son propre espace URI et réduire le couplage avec le client.

Quand un client pour le service envoie une requête avec succès pour créer une nouvelle ressource, le service répond 201 CRÉÉE et donne l'URI à laquelle on peut accéder à la nouvelle ressource dans le domaine d'en-tête d'emplacement.

un client devrait être autorisé à stocker cet URI pour permettre un accès direct à la ressource à l'avenir et si oui pour combien de temps? Si URIs sont mises en cache par le client, cela semble être la mise en place d'une situation dans laquelle chaque fois que le serveur change de mise en page URI, il devra se assurer servi obtient une redirection permanente lorsque les anciens URIs sont accessibles. Sinon, le client se casse. Depuis plusieurs années, ce système de réoriente pourrait sortir de la main.

Cette situation ne semble pas avoir donné le serveur beaucoup plus de contrôle sur son espace URI qu'une approche hybride REST-RPC en utilisant des modèles d'URI.

Il y a beaucoup d'informations disponibles sur les représentations de mise en cache, mais qu'en est-URIs de mise en cache dans les systèmes RESTful conduit hypertexte?

Answer 1

Rappelez-vous que Tim Berners-Lee a dit: « URL fraîches ne changent pas ». Une fois que le serveur remet un URI au client, il est maintenant le travail du serveur pour garder l'URI de travail à l'avenir (par exemple) l'envoi d'une réponse Déplacé-permanente dans le cas où l'URI a changé et que quelqu'un demande l'ancien.

est en fait ce qui encourage beaucoup à la conception URIs opaque, comme base de données basée sur ids ou estampilles, plutôt que d'utiliser une propriété humaine lisible de la ressource dans l'URI. Tout ce que les gens comprennent, ils veulent changer.

Answer 2

Oui, le client doit être autorisé à stocker l'URI. Tant et aussi longtemps qu'il le souhaite. Comme mentionné Licky un client intelligent peut utiliser une réponse Déplacé-permanente de mettre à jour ses signets.

Si vous pensez à ce sujet, nous avons la meilleure situation possible. Vous pouvez modifier les urls sur le serveur, tout en choisissant de soutenir encore les anciens clients aussi longtemps que nous choisissons, et les clients intelligents peuvent efficacement auto se mettre à jour les nouvelles urls.

Depuis combien de temps vous choisissez de continuer à soutenir ces vieux urls est vraiment une décision qui doit être faite sur la base des clients existants et la facilité avec laquelle ils peuvent être maintenus.

Pour moi, c'est une énorme amélioration par rapport aux problèmes de versioning avec des interfaces de type RPC.

Answer 3

Je sais que c'est une vieille question, mais je pense qu'il ya un sous-composant les réponses que je vois ici qui n'a pas été pris en compte.

Rappelez-vous que vous n'êtes pas récupérer la ressource du serveur, mais vous récupérez une représentation d'une ressource. La ressource elle-même peut avoir son changement d'identification primaire, ou être rapatrié, ou autre chose, mais la représentation qui a été renvoyée au client sur la création de ressources peut (ou non) être valable indépendamment; il est une question de situation.

À titre d'exemple, considérons un système de chargement de contenu modéré; un utilisateur peut avoir la possibilité de télécharger le contenu pour examen par les modérateurs qui peuvent éventuellement causer le contenu à être exposé à un plus large public / marché. Le téléchargement initial, le serveur peut répondre par un URI qui dirige vers (par exemple) « utilisateurs / {IDutilisateur} / téléchargé / {} ContentID » pour cette représentation de ce contenu. À un certain moment, les modérateurs peuvent décider de promouvoir le contenu à une « page d'accueil »; que la représentation du contenu peut alors être disponible à l'URI de « contenu / {} ContentID »; cela ne devrait pas empêcher la Uploader originale d'accéder à leurs données à « utilisateurs / {IDutilisateur} / téléchargé / {} ContentID »; rien ne dit qu'il doit y avoir une redirection permanente, et en fait, il y a de bonnes raisons pour qu'il n'y ait pas être; si l'utilisateur décide qu'ils veulent supprimer le contenu, ils devraient être en mesure d'effectuer une suppression du contenu; il est sans doute beaucoup de faveur que les utilisateurs faisant les représentations DELETE de contenu de leurs propres « téléversés » endroits. Toutefois, si les conditions du site indiquent que les droits des utilisateurs au contenu téléchargé sont révoqués (pas rare), il peut être judicieux d'avoir le processus de promotion de la modération éliminer efficacement le contenu de la propre zone de l'utilisateur, ce qui provoque un « mouvement permanent ».

Il est vraiment dépendant entièrement de la situation spécifique; la validité d'un URI en cache dépend complètement des politiques du serveur. Au moins, je pense qu'une demande à un URI non valide (qui peut avoir déjà été valide) devrait provoquer une réponse (compatible avec HATEOAS) qui peut permettre au client de « redécouvrir » la ressource (représentation) qu'ils cherchaient ; à tout le moins, un lien vers le point d'entrée.

Answer 4

Depuis l'un des principes de REST est que les ressources sont adressables, il semble tout à fait acceptable pour un client de garder une trace de l'adresse (URI) pour une ressource donnée. URIs de ressources devrait être l'un des « points d'entrée bien connus » dont vous avez parlé.