Pourquoi l'en-tête d'emplacement HTTP est-il défini uniquement pour les requêtes POST/réponses 201 (créées) ?

Question

En ignorant un instant les réponses 3xx, je me demande pourquoi l'en-tête d'emplacement HTTP n'est utilisé qu'en conjonction avec les requêtes POST/réponses 201 (créées).

Du Spécification RFC 2616:

Pour les réponses 201 (Créé), l'emplacement est celui de la nouvelle ressource créée par la requête.

Il s'agit d'un comportement largement pris en charge, mais pourquoi ne devrait-il pas être utilisé avec d'autres méthodes HTTP ?Prendre la Spécification de l'API JSON par exemple:

Il définit un lien d'auto-référencement pour la ressource actuelle à l'intérieur de la charge utile JSON (pas rare pour les API RESTful).Ce lien est inclus dans chaque charge utile.La spécification dit que vous DOIT inclure un en-tête d'emplacement HTTP, si vous créez un nouveau document via POST et que la valeur est la même que celle du lien auto-référencé dans la charge utile, mais ceci est SEULEMENT nécessaire pour le POST.Pourquoi s'embêter avec un coutume format pour un lien auto-référencé, si vous pouviez simplement utiliser l'en-tête d'emplacement HTTP ?

Note:Ce n'est pas spécifique à l'API JSON.C'est pareil pour HAL, Hyper-schéma JSON ou d'autres normes.

Note 2:Ce n'est même pas spécifique à l'en-tête d'emplacement HTTP car c'est la même chose avec l'en-tête de lien HTTP.Comme vous pouvez le constater, l'API JSON, HAL et JSON Hyper-Schema définissent non seulement des conventions pour les liens auto-référencés, mais également pour exprimer des informations sur les ressources associées ou les actions possibles pour une ressource.Mais il semble qu’ils pourraient tous simplement utiliser l’en-tête du lien HTTP.(Ils pourraient même placer le lien d’auto-référencement dans l’en-tête du lien HTTP, s’ils ne souhaitent pas utiliser l’en-tête d’emplacement HTTP.)

Je ne veux pas déclamer, cela semble juste être une sorte de « réinventer la roue ».Cela semble également très limitatif :si vous utilisiez simplement l'en-tête d'emplacement/lien HTTP, peu importe si vous demandez JSON, XML ou autre dans votre en-tête d'acceptation HTTP et vous obtiendriez des méta-informations utiles sur votre ressource sur une requête HEAD, ce qui ne le serait pas. contiennent les liens si vous utilisez l'API JSON, HAL ou JSON Hyper-Schema.

Answer 1

La sémantique du Location l'en-tête n'est pas celui d'un lien d'auto-référencement, mais d'un lien que l'agent utilisateur doit suivre afin de compléter la requête.Cela a du sens dans les redirections, et lorsque vous créez une nouvelle ressource qui se trouvera dans un nouvel emplacement, vous devriez vous y rendre.Si votre demande est déjà complétée, ce qui signifie que vous disposez déjà d'une représentation complète de la ressource souhaitée, cela n'a pas de sens de renvoyer un Location.

Le Link L'en-tête peut être considéré comme sémantiquement équivalent à un lien hypertexte, mais il doit être utilisé pour référencer des métadonnées liées à la ressource donnée lorsque le type de média n'est pas compatible hypermédia, afin qu'il ne remplace pas la fonctionnalité d'un lien vers des ressources associées dans une API RESTful.

La nécessité d'un format de lien personnalisé dans la représentation de la ressource est inhérente à la nécessité de dissocier la ressource de l'implémentation et du protocole sous-jacents.REST n'est pas couplé à HTTP et tout protocole pour lequel il existe un schéma d'URI valide peut être utilisé.Si vous décidez d'utiliser le Link en-tête pour tous les liens, vous vous connectez à HTTP.

Disons que vous présentez un lien FTP que les clients doivent suivre.Où serait le Link dans ce cas?

Answer 2

La sémantique de l'en-tête de localisation dépend du code d'état. Pour 201, il relie la ressource nouvellement créée, mais dans les demandes 3xx, il peut avoir plusieurs significations (bien que similaires). Je pense que c'est pourquoi il est généralement évité pour d'autres usages.

L'alternative est l'en-tête de l'emplacement de contenu, qui a toujours une signification cohérente. Il indique au client l'URL canonique la ressource qu'il a demandée. Il est purement informatif (contrairement à l'emplacement, qui devrait être traité par le client).

Donc, l'en-tête de contenu semble se rapprocher de ressembler à un lien auto-référençant. Cependant, l'emplacement de contenu a également Non défini Comportement pour mettre et poster . Il semble également être assez rarement utilisé.

Ce blogs post Emplacement VS Content-Localisation est une belle comparaison. Voici une citation:

Enfin, aucun en-tête n'est destiné à une liaison à usage général.

en somme, nécessitant une liaison standardisée et autonome dans le corps semble être une bonne idée. Cela évite beaucoup de confusion du côté du client.