Version courte de la question:
fait "get" à une URI particulière doit correspondre à ce qui a été "mis" à cet URI?
Je pense pas. Voici pourquoi:
Étant donné qu'une ressource est une chose abstraite théoriquement inconnaissable par le client, lorsque nous faisons une place, nous ne devons pas envoyer une représentation. Basé sur la lutte contre la RFC2616, il ne semble pas tout à fait précisé sur ce que cela signifie pour une ressource qui présente de nombreuses représentations (potentiellement infinies?), Mais voici mes pensées; S'il vous plaît dites-moi si vous acceptez:
Mon attendant est que si je mettais une représentation à une ressource, toutes les autres représentations de la ressource à cette URI doivent être respectées (potentiellement mises à jour) si nécessaire. En d'autres termes, vous racontez la ressource "Utilisez cette représentation pour vous redéfinir".
Ainsi, je devrais pouvoir faire cela:
MIS / RESSOURCES / FOO / MYVACATION
Type de contenu: Image / JPG
...et suivi avec ceci:
Obtenir / Ressources / FOO / MyVacation
Accepter: Image / PNG
...et obtenir la version mise à jour de MyVACATION dans un format différent (en supposant que le serveur sait comment faire cela). Extrapolant de cela, cette "image + métadonnées" atomique composite doit également être légal:
MIS / RESSOURCES / FOO / MYVACATION
Type de contenu: Multipart / Form-Datadisposition de contenu: données de formulaire; Nom = "Document"
Type de contenu: Image / JPG
[..]
Disposition de contenu: données de formulaire; Nom = "IPTC"
Type de contenu: Application / IPTC
[..]
Disposition de contenu: données de formulaire; Nom = "exif"
Type de contenu: Application / Exif
[..]Et puis, car la négociation de contenu côté serveur (RFC2616 Section 12.1) peut avoir lieu sur la base de n'importe quoi, nous pouvons par défaut du contenu "Document" pour cela:
Obtenir / Ressources / FOO / MyVacation
Type de contenu: Image / JPG
[..]ou si vous croyez que je fais que RFC 2396 Section 3.4 "Le composant de la requête est une chaîne d'informations à interpréter par la ressource." signifie qu'un URI avec une chaîne de requête fait référence à la même ressource qu'une URI sans chaîne de requête (et est isomorphe avec simplement envoyer des données d'application / formes-formes-urlencodes à la ressource), cela devrait également être légal:
Obtenir / Ressources / FOO / MYVACATION? CONTENU = EXIF
Type de contenu: Application / Exif
[..]La description de Met dit:
la méthode de vente demande que l'entité ci-jointe soit stockée sous la demande fournie - URI.
Pour moi, c'est assez anti-repos, sauf si vous le lisez de manière très libérale. Mon interprétation est "la méthode de vente demande qu'une ressource soit créée ou mise à jour à la demande fournie - URI basée sur la représentation de l'entité ci-jointe."
Plus tard, nous obtenons:
La différence fondamentale entre les demandes de poste et de mise en place est reflétée dans le sens différent de la demande-Uri. L'URI d'une demande postale identifie la ressource qui gérera l'entité fermée. Cette ressource pourrait être un processus d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande de vente identifie l'entité jointe à la demande - l'agent utilisateur sait ce qu'Iri est destiné et que le serveur ne doit pas tenter d'appliquer la demande à une autre ressource.
Nous devons la lire de la même manière créative, mais les bits de clé ici sont "sait quel URI est destiné" et "appliquer la demande".
Donc, pour moi, la représentation est revenue à une URI donnée ne doit pas nécessairement être la même représentation qui a été mises à l'URI donnée, il doit simplement être cohérent.
vrai ou faux?
4 Réponses :
Si vous transformez alors, il serait logique que ce que vous mais, si vous mettre n'est pas ce que vous obtenez , donc je ne vois pas pourquoi c'est un problème.
mettre un utilisateur avec certaines informations, alors lorsque vous utilisez obtenez , alors il devrait récupérer cette personne, comme je mets ma 4ème photo de vacances , quand j'appelle obtenez Je m'attends à ce que la photo, mais elle peut être transformée en convertissant à un format différent ou en convertissant d'autres transformations, mais si je reçois la 5ème photo à la place, c'est un problème .
Sur la base du fait que la négociation de contenu peut renvoyer différentes représentations du même URI, je suis sûr que ce que vous avez mis ne doit pas nécessairement être le même que ce que vous récupérez.
Tout à fait juste. Utilisation de l'en-tête de type de contenu, c'est parfaitement légal pour poster un objet XML, puis obtenir une représentation JSON ou XHTML. De telles transformations rendent plus simples d'utiliser votre API reposante dans de nombreuses applications différentes.
@Darrel - Je suis d'accord, bien que le cas d'une inconvénient me fait me sentir un peu coupable. Je compte sur la "négociation latérale du serveur peut utiliser tous les critères qu'il souhaite" Clause, qui se sent squishier que je voudrais. @Lars - La poste est une bête différente, cependant. La définition de la mise est beaucoup plus contrainte, d'où ma question.
Vos hypothèses sont correctes. Le get ne doit pas nécessairement retourner la même représentation comme ce que vous mettez, mais il faut que ce soit la même ressource . .
Je travaille actuellement sur une application Web qui retournera toute ressource en tant que XHTML, JSON ou un dialecte XML personnalisé, en fonction de ce que vous demandez dans les en-têtes de négociation de contenu. Donc, un navigateur verra le HTML par défaut. D'autres clients HTTP, y compris XMLHTTPRequest, peuvent obtenir le JSON, etc. Ce sont toutes des représentations de la même ressource sur le même URI.
De même, notre application acceptera une mise ou un poste dans l'un des formats pris en charge (sous réserve de la sémantique de la ressource ou de la collecte particulière en question.)
Je suis d'accord avec les autres réponses que la ressource que vous mettez n'est pas nécessaire pour être identique à celle que vous recevez ultérieurement. Je voulais ajouter une partie de mon expérience à cette question autour de cette zone.
Vous devez faire très attention lorsque vous comptez sur la négociation de contenu. Il est très délicat d'avoir raison et si vous ne le faites pas correctement conduit à des problèmes d'utilisateur méchant. Faisons un exemple basé sur des images ...
Si Alice met une image dans un format RAW, alors Bob peut obtenir l'image en tant que JPEG (via une transformation RAW-> JPEG SERVER) et Alice peut obtenir l'image dans un format RAW; Pas de problème. Cependant, si Bob met un JPEG, il n'ya aucun moyen de revenir au format brut pour Alice. Dans le cas des photos de vacances, le manque de transformations symétriques peut ne pas être une grosse affaire, mais dans des images médicales, ce serait.
Un autre domaine où le manque de transformations symétriques vous mords est dans des représentations où l'on a un schéma et l'autre ne le fait pas. Dans ce cas, sur le côté serveur, vous finissez par faire des conventions pour savoir comment transformer entre eux. Mais vous rencontrez de gros problèmes lorsque vous avez affaire à des documents avec des schémas qui changent au fil du temps et sont hors de votre contrôle. Chaque fois que les changements de schéma, vous devez mettre à jour toutes vos transformations pour la nouvelle forme de schéma, tout en appuyant des ressources utilisant l'ancien schéma. La négociation de contenu devient rapidement plus de problèmes que sa valeur, à l'exception de quelques circonstances limitées. L'un des domaines où il peut être gérable est si vous contrôlez pleinement la représentation des ressources et son schéma sous-jacent. Un autre domaine est si les formats de ressources sont des normes et qu'il est possible de faire des transformations symétriques entre les différents formats.
J'ai récemment découvert que RFC2616 a été remplacé par RFC3986, qui définit la requête de telle sorte qu'il puisse être utilisé pour localiser la ressource. Je ne suis pas sûr que j'aime cette nouvelle définition. : - /