Perché l'intestazione della posizione HTTP è impostata solo per le risposte Post Richieste / 201 (creato)?

Question

Ignorando le risposte 3xx per un momento, mi chiedo perché l'intestazione della posizione HTTP viene utilizzata solo in combinazione con le risposte post-richieste / 201 (creato).

Dal RFC 2616 specifiche : .

.

Per 201 (creato) risposte, la posizione è quella della nuova risorsa creata dalla richiesta.

Questo è un comportamento ampiamente supportato, ma perché non dovrebbe essere utilizzato con altri metodi HTTP? Prendi il JSON API Spec come esempio:

Definisce un collegamento autofigurativo per la risorsa corrente all'interno del carico utile JSON ( no Non comune per API riposanti ). Questo collegamento è incluso in ogni carico utile. La specifica dice che deve includi un'intestazione di posizione HTTP, se si crea un nuovo documento via Post e che il valore è uguale al link di autoferenza nel carico utile, ma questo è solo Necessario per posta. Perché preoccuparsi di un formato personalizzato per un collegamento autofigurativo, se è possibile utilizzare l'intestazione della posizione HTTP?

Nota: questo non è specifico per JSON API. È lo stesso per hal , json hyper-schema o altri standard.

Nota 2: non è nemmeno specifico per l'intestazione della posizione HTTP in quanto è la stessa con l'intestazione del collegamento HTTP. Come puoi vedere l'API JSON, HAL e JSON Hyper-Schema non solo definiscono le convenzioni per i collegamenti autofiguranti, ma anche per esprimere informazioni su risorse correlate o possibili azioni per una risorsa. Ma sembra che tutti potessero usare l'intestazione del collegamento HTTP. (Potrebbero anche mettere il collegamento autofigurativo nell'intestazione del collegamento HTTP, se non vogliono utilizzare l'intestazione della posizione HTTP.)

Non voglio rant, sembra solo essere una sorta di "reinventare la ruota". Sembra anche essere molto limitante: se useresti semplicemente l'intestazione di posizione / link HTTP, non importa se chiedi JSON, XML o qualunque sia la tua intestazione HTTP Accettimenti e si ottiene utili informazioni sulla tua risorsa Una richiesta di testa, che non conterrebbe i collegamenti se useresti JSON API, HAL o JSON Hyper-Schema.

Answer 1

La semantica dell'intestazione Location non è quella di un collegamento auto-referenziamento, ma di un collegamento dovrebbe seguire l'utente-agente dell'utente per completare la richiesta. Ciò ha senso nei reindirizzamenti, e quando crei una nuova risorsa che sarà in una nuova posizione in cui dovresti andare. Se la tua richiesta è già stata completata, il che significa già una rappresentazione completa della risorsa che volevi, non ha senso restituire un Location.

L'intestazione Link può essere considerata semanticamente equivalente a un collegamento ipertestuale, ma dovrebbe essere utilizzato per fare riferimento ai metadati relativi alla risorsa specificata quando il tipo di supporto non è consapevole di Ipermedia, quindi non sostituisce la funzionalità di a Link alle risorse correlate in un'API riposante.

La necessità di un formato di collegamento personalizzato nella rappresentazione delle risorse è inerente alla necessità di disaccoppiare la risorsa dall'implementazione e del protocollo sottostante. Il riposo non è accoppiato a http e qualsiasi protocollo per il quale è possibile utilizzare uno schema URI valido. Se hai deciso di utilizzare l'intestazione Link per tutti i collegamenti, stai accoppiando a http.

Diciamo di presentare un link FTP per i clienti da seguire. Dove sarebbe il Link in quel caso?

Answer 2

Il semantico dell'intestazione della posizione dipende dal codice di stato. Per il 201, si collega alla risorsa appena creata, ma in richieste 3xx può avere significati multipli (anche se simili). Penso che sia per questo che è generalmente evitato per altri usi.

L'alternativa è l'intestazione del contenuto-posizione, che ha sempre un significato coerente. Dice al cliente l'URL canonico della risorsa richiesta. È puramente informativo (in contrasto con la posizione, che dovrebbe essere elaborato dal cliente).

Allora, l'intestazione del contenuto-posizione sembra più attento ad assomigliare a un collegamento auto-referenziamento. Tuttavia, il contenuto-location ha anche No definito comportamento per mettere e post . Sembra anche essere abbastanza raramente usato.

Questo post post Posizione vs content-location è un bel confronto. Ecco una citazione:

.

Infine, né l'intestazione è destinata per il collegamento in generale.

In somma, richiedendo un collegamento standardizzato, autonomo nel corpo sembra essere una buona idea. Evita molta confusione sul lato client.