¿Por qué el encabezado de ubicación HTTP solo está configurado para solicitudes POST/respuestas 201 (creadas)?

Question

Ignorando las respuestas 3xx por un momento, me pregunto por qué el encabezado de ubicación HTTP solo se usa junto con solicitudes POST/respuestas 201 (creadas).

Desde el Especificaciones RFC 2616:

Para las respuestas 201 (Creadas), la Ubicación es la del nuevo recurso que fue creado por la solicitud.

Este es un comportamiento ampliamente admitido, pero ¿por qué no debería usarse con otros métodos HTTP?Toma el Especificación de API JSON como ejemplo:

Define un enlace de autorreferencia para el recurso actual dentro de la carga útil JSON (no es infrecuente para las API RESTful).Este enlace está incluido en cada carga útil.La especificación dice que tú DEBE incluya un encabezado de ubicación HTTP, si crea un nuevo documento a través de POST y el valor es el mismo que el enlace de autorreferencia en la carga útil, pero esto es SOLO necesario para la publicación.¿Por qué molestarse con un costumbre formato para un enlace de autorreferencia, ¿si pudiera usar el encabezado de ubicación HTTP?

Nota:Esto no es específico de la API JSON.Es lo mismo para HAL, Hiperesquema JSON u otras normas.

Nota 2:Ni siquiera es específico del encabezado de ubicación HTTP, ya que es lo mismo con el encabezado del enlace HTTP.Como puede ver, la API JSON, HAL y JSON Hyper-Schema no solo definen convenciones para enlaces de autorreferencia, sino también para expresar información sobre recursos relacionados o posibles acciones para un recurso.Pero parece que todos podrían usar el encabezado del enlace HTTP.(Incluso podrían colocar el enlace de autorreferencia en el encabezado del enlace HTTP, si no quieren utilizar el encabezado de ubicación HTTP).

No quiero despotricar, simplemente parece una especie de "reinventar la rueda".También parece muy limitante:Si simplemente usara el encabezado de ubicación/enlace HTTP, no importa si solicita JSON, XML o lo que sea en su encabezado de aceptación HTTP y obtendría metainformación útil sobre su recurso en una solicitud HEAD, lo cual no contiene los enlaces si utilizaría JSON API, HAL o JSON Hyper-Schema.

Answer 1

La semántica de la Location El encabezado no es el de un enlace de autorreferencia, sino el de un enlace que el agente de usuario debe seguir para completar la solicitud.Eso tiene sentido en las redirecciones, y cuando creas un nuevo recurso, estará en una nueva ubicación a la que debes ir.Si su solicitud ya está completa, lo que significa que ya tiene una representación completa del recurso que deseaba, no tiene sentido devolver una Location.

El Link El encabezado puede considerarse semánticamente equivalente a un enlace de hipertexto, pero debe usarse para hacer referencia a metadatos relacionados con el recurso dado cuando el tipo de medio no es compatible con hipermedia, por lo que no reemplaza la funcionalidad de un enlace a recursos relacionados en una API RESTful.

La necesidad de un formato de enlace personalizado en la representación del recurso es inherente a la necesidad de desacoplar el recurso de la implementación y el protocolo subyacentes.REST no está acoplado a HTTP y se puede utilizar cualquier protocolo para el que exista un esquema URI válido.Si decidiste utilizar el Link encabezado para todos los enlaces, estás acoplando a HTTP.

Supongamos que presenta un enlace FTP para que los clientes lo sigan.¿Dónde estaría el Link ¿en ese caso?

Answer 2

El semántico del encabezado de ubicación depende del código de estado. Para 201, se relaciona con el recurso recién creado, pero en las solicitudes de 3xx puede tener significados múltiples (aunque símiliares). Creo que es por eso que generalmente se evita para otros usos.

La alternativa es el encabezado de la ubicación de contenido, que siempre tiene un significado consistente. Le dice al cliente la URL canónica el recurso que solicitó. Es puramente informativo (en contraste con la ubicación, que se espera que sea procesada por el cliente).

Entonces, el encabezado de la ubicación de contenido parece acercarse a un enlace de auto-referencias. Sin embargo, la ubicación del contenido también tiene una no definido Comportamiento para poner y publicar . También parece ser bastante utilizado.

Estos blogs posts Ubicación vs contenido-Ubicación Es una buena comparación. Aquí hay una cita:

Finalmente, ni el encabezado está destinado a la vinculación de propósito general.

En resumen, que requiere un enlace estandarizado en el cuerpo parece ser una buena idea. Evita mucha confusión en el lado del cliente.