Por que o cabeçalho de localização HTTP está definido apenas para solicitações POST/respostas 201 (criadas)?

Question

Ignorando as respostas 3xx por um momento, me pergunto por que o cabeçalho de localização HTTP é usado apenas em conjunto com respostas POST requests/201 (Created).

De Especificação RFC 2616:

Para respostas 201 (Criadas), o Local é o do novo recurso que foi criado pela solicitação.

Este é um comportamento amplamente suportado, mas por que não deveria ser usado com outros métodos HTTP?Levar a Especificação da API JSON como um exemplo:

Ele define um link de auto-referência para o recurso atual dentro da carga JSON (não é incomum para APIs RESTful).Este link está incluído em cada carga útil.A especificação diz que você DEVE inclua um cabeçalho de localização HTTP, se você criar um novo documento via POST e se o valor for o mesmo do link de auto-referência na carga útil, mas isso é APENAS necessário para POST.Por que se preocupar com um personalizado formato para um link de auto-referência, se você pudesse usar apenas o cabeçalho de localização HTTP?

Observação:Isso não é específico da API JSON.É o mesmo para HAL, Hiperesquema JSON ou outros padrões.

Nota 2:Não é nem específico para o cabeçalho de localização HTTP, pois é o mesmo para o cabeçalho do link HTTP.Como você pode ver a API JSON, HAL e JSON Hyper-Schema não apenas definem convenções para links de auto-referência, mas também para expressar informações sobre recursos relacionados ou possíveis ações para um recurso.Mas parece que todos eles poderiam usar apenas o cabeçalho do link HTTP.(Eles podem até colocar o link de auto-referência no cabeçalho do link HTTP, se não quiserem usar o cabeçalho de localização HTTP.)

Não quero reclamar, apenas parece ser uma espécie de “reinventação da roda”.Também parece ser muito limitante:se você usasse apenas o cabeçalho de localização/link HTTP, não importa se você solicita JSON, XML ou qualquer outro em seu cabeçalho de aceitação HTTP e você obteria meta-informações úteis sobre seu recurso em uma solicitação HEAD, o que não aconteceria contenha os links se você usar JSON API, HAL ou JSON Hyper-Schema.

Answer 1

A semântica do Location O cabeçalho não é um link de auto-referência, mas um link que o agente do usuário deve seguir para concluir a solicitação.Isso faz sentido em redirecionamentos, e quando você cria um novo recurso que estará em um novo local para onde você deve ir.Se sua solicitação já estiver concluída, o que significa que você já possui uma representação completa do recurso desejado, não faz sentido retornar um Location.

O Link cabeçalho pode ser considerado semanticamente equivalente a um link de hipertexto, mas deve ser usado para fazer referência a metadados relacionados a um determinado recurso quando o tipo de mídia não reconhece hipermídia, para que não substitua a funcionalidade de um link para recursos relacionados em uma API RESTful.

A necessidade de um formato de link personalizado na representação de recursos é inerente à necessidade de dissociar o recurso da implementação e do protocolo subjacentes.REST não está acoplado ao HTTP e qualquer protocolo para o qual exista um esquema de URI válido pode ser usado.Se você decidiu usar o Link cabeçalho para todos os links, você está acoplando ao HTTP.

Digamos que você apresente um link FTP para os clientes seguirem.Onde estaria o Link nesse caso?

Answer 2

A semântica do cabeçalho do local depende do código de status. Para 201, liga-se ao recurso recém-criado, mas em solicitações de 3xx, ela pode ter múltiplos significados (apesar de similiar). Eu acho que é por isso que é geralmente evitado para outros usos.

A alternativa é o cabeçalho do local de conteúdo, que sempre tem um significado consistente. Diz ao cliente a URL canônica o recurso solicitou. É puramente informativo (em contraste com a localização, que deve ser processada pelo cliente).

Então, o cabeçalho do local de conteúdo parece mais próximo se assemelhando a um link de auto-referência. No entanto, o local de conteúdo também tem não definido comportamento para colocar e postar . Também parece ser raramente usado.

estes blogs post localização vs conteúdo-localização é uma boa comparação. Aqui está uma cotação:

.

Finalmente, nem o cabeçalho é destinado a vinculação de propósito geral.

Em suma, exigindo uma autoconfiança padronizada no corpo parece ser uma boa ideia. Evita muita confusão no lado do cliente.