PUT

Un serveur d'origine DEVRAIT ignorer les champs d'en-tête non reconnus reçus dans une demande PUT (c'est-à-dire, Un serveur d'origine doit vérifier que la représentation PUT est cohérente avec toutes les contraintes que le serveur a pour la ressource cible et qui ne peuvent pas être ou ne seront pas modifiées par le PUT. Cela est particulièrement important lorsque le serveur d'origine utilise des informations de configuration internes relatives à l'URI pour définir les valeurs des métadonnées de représentation dans les réponses GET. Lorsqu'une représentation PUT est incohérente avec la ressource cible, le serveur d'origine DEVRAIT soit les rendre cohérentes, en transformant la représentation ou en modifiant la configuration de la ressource, soit répondre par un message d'erreur approprié contenant suffisamment d'informations pour expliquer pourquoi la représentation n'est pas appropriée. Les codes d'état 409 (Conflict) ou 415 (Unsupported Media Type) sont suggérés, ce dernier étant spécifique aux contraintes sur les valeurs Content-Type.

Par exemple, si la ressource cible est configurée pour toujours avoir un Content-Type de "text/html" et que la représentation PUT a un Content-Type de "image/jpeg", le serveur d'origine devrait faire l'une des choses suivantes:

• a. reconfigurer la ressource cible pour refléter le nouveau type de média;
• b. transformer la représentation PUT dans un format compatible avec celui de la ressource avant de l'enregistrer en tant que nouvel état de la ressource ; ou,
• c. rejeter la demande avec une réponse 415 (Unsupported Media Type) indiquant que la ressource cible est limitée à "text/html", en incluant éventuellement un lien vers une ressource différente qui serait une cible appropriée pour la nouvelle représentation.

HTTP ne définit pas exactement comment une méthode PUT affecte l'état d'un serveur d'origine au-delà de ce qui peut être exprimé par l'intention de la demande de l'agent utilisateur et la sémantique de la réponse du serveur d'origine. Il ne définit pas ce qu'est une ressource, dans tous les sens du terme, au-delà de l'interface fournie par HTTP. Elle ne définit pas comment l'état de la ressource est "stocké", ni comment ce stockage peut changer à la suite d'une modification de l'état de la ressource, ni comment le serveur d'origine traduit l'état de la ressource en représentations. Un serveur d'origine NE DOIT PAS envoyer un champ d'en-tête de validation (section 7.2), tel qu'un champ ETag ou Last-Modified, dans une réponse réussie à PUT, à moins que les données de représentation de la demande n'aient été sauvegardées sans aucune transformation appliquée au corps (c'est-à-dire que les nouvelles données de représentation de la ressource sont identiques aux données de représentation reçues dans la demande PUT) et que la valeur du champ de validation ne reflète la nouvelle représentation. Cette exigence permet à un agent utilisateur de savoir si le corps de la représentation qu'il a en mémoire reste à jour à la suite de la demande PUT, et n'a donc pas besoin d'être récupéré à nouveau auprès du serveur d'origine, et si le(s) nouveau(x) validateur(s) reçu(s) dans la réponse peut (peuvent) être utilisé(s) pour de futures demandes conditionnelles afin d'éviter les écrasements accidentels (section 5.2).

La différence fondamentale entre les méthodes POST et PUT est mise en évidence par l'intention différente de la représentation jointe. La ressource cible d'une requête POST est censée traiter la représentation jointe conformément à sa propre sémantique, alors que la représentation jointe d'une requête PUT est définie comme remplaçant l'état de la ressource cible. Par conséquent, l'intention de PUT est idempotente et visible par les intermédiaires, même si l'effet exact n'est connu que par le serveur d'origine.

L'interprétation correcte d'une demande PUT suppose que l'agent utilisateur sache quelle ressource cible est souhaitée. Un service qui sélectionne un URI approprié pour le compte du client, après avoir reçu une demande de changement d'état, DEVRAIT être mis en œuvre en utilisant la méthode POST plutôt que PUT. Si le serveur d'origine n'effectue pas le changement d'état PUT demandé pour la ressource cible et souhaite plutôt qu'il soit appliqué à une ressource différente, par exemple lorsque la ressource a été déplacée vers un URI différent, le serveur d'origine DOIT envoyer une réponse 3xx (Redirection) appropriée ; l'agent utilisateur PEUT alors prendre sa propre décision concernant la redirection ou non de la demande.

Une demande PUT appliquée à la ressource cible peut avoir des effets secondaires sur d'autres ressources. Par exemple, un article peut avoir un URI pour identifier "la version actuelle" (une ressource) qui est séparé des URI identifiant chaque version particulière (différentes ressources qui, à un moment donné, ont partagé le même état que la ressource de la version actuelle). Une demande PUT réussie sur l'URI de la "version actuelle" peut donc créer une nouvelle ressource de version en plus de modifier l'état de la ressource cible, et peut également entraîner l'ajout de liens entre les ressources connexes.

Un serveur d'origine qui autorise PUT sur une ressource cible donnée DOIT envoyer une réponse 400 (Bad Request) à une demande PUT qui contient un champ d'en-tête Content-Range (Section 4.2 de [RFC7233]), étant donné que la charge utile est susceptible d'être un contenu partiel qui a été envoyé par erreur comme une représentation complète. Les mises à jour partielles de contenu sont possibles en ciblant une ressource identifiée séparément dont l'état chevauche une partie de la ressource plus large, ou en utilisant une méthode différente qui a été spécifiquement définie pour les mises à jour partielles (par exemple, la méthode PATCH définie dans [RFC5789]).

Les réponses à la méthode PUT ne peuvent pas être mises en cache. Si une requête PUT réussie passe par un cache qui a une ou plusieurs réponses stockées pour l'URI de requête effectif, ces réponses stockées seront invalidées (voir la section 4.4 de [RFC7234]).

Les réponses à la méthode PUT ne peuvent pas être mises en cache.