Intestazione posizione POST HTTP durante la creazione di più risorse

Question

Il HTTP/1.1 standard afferma che se un'operazione POST determina la creazione di una risorsa, la risposta deve includere un'intestazione Location con l'indirizzo della nuova risorsa.

Se una risorsa è stata creata sul server di origine, la risposta DOVREBBE essere 201 (Creato) e contengono un'entità che descrive lo stato della richiesta e si riferisce alla nuova risorsa, e un colpo di testa posizione (vedi sezione 14.30).

e nella sezione 14.30,

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

Ora supponiamo che il mio API permette la creazione lotto di risorse da parte POST ing una matrice per l'URL della risorsa di raccolta. Per esempio:

POST /books 
[ 
    { 
     "name": "The Colour of Magic", 
     "published": "1983" 
    }, 
    { 
     "name": "The Light Fantastic", 
     "published": "1986" 
    } 
] 

Da due \book\{bookId} risorse sono state create, quello che dovrebbe essere il valore del Location intestazione in questo caso?

La domanda Http post response after multiple new resource creation? è simile, ma richiede l'entità di risposta, non le intestazioni (e non ha risposta).

Answer 1

So che questa risposta è in ritardo alla partito ma credo che la soluzione migliore sia creare una nuova risorsa Batch con un identificatore uuid che wo uld restituire l'elenco di URL del libro che sono stati aggiunti utilizzando un URL come questo:

http://api.example.com/batches/{uuid} 

ad es.

http://api.example.com/batches/2b9b251f71a4b2901d66e04725bc0c9cb5843c74 

Allora la vostra POST o PUT può restituire l'URL di cui sopra sul suo Location: {url} intestazione e un codice di stato 201 - Created.

Se si quindi GET quell'URL, verrà quindi creato l'elenco di URL creati in quel batch e qualsiasi altra informazione sul batch come il suo uuid e l'ora/la data in cui è stato creato.

{ 
    "uuid": "2b9b251f71a4b2901d66e04725bc0c9cb5843c74", 
    "datetime": "2005-08-15T15:52:01+00:00", 
    "books": [ 
    "http://api.example.com/books/the-colour-of-magic", 
    "http://api.example.com/books/the-light-fantastic" 
    ] 
} 

Queste risorse potrebbero quindi avere un TTL di un'ora o un mese, qualunque sia la vostra scelta. Potrebbero vivere per sempre se vuoi; qualunque sia il tuo caso d'uso.

Answer 2

RFC 2616 è obsoleto. Smettila di guardarlo tranne che per scopi storici.

La specifica corrente, RFC 7231, dice:

"Se una o più risorse sono stati creati sul server di origine a seguito del trattamento con successo una richiesta POST, il server di origine deve inviare un 201 (Creato) risposta contenente un campo dell'intestazione Location che fornisce un identificatore per la risorsa primaria creata (Sezione 7.1.2) e una rappresentazione che descrive lo stato della richiesta mentre si riferisce alle nuove risorse. " - http://greenbytes.de/tech/webdav/rfc7231.html#POST

E sì, questo non aiuta molto quando non c'è una risorsa "primaria".

Answer 3

Penso che ci si trovi in ​​un caso d'uso particolare per l'intestazione Location. Nel caso di creazione di massa, il risultato del processo viene generalmente fornito all'interno del contenuto restituito stesso. Di fatto, l'elaborazione può essere completamente o parzialmente vincente. Voglio dire che tutti gli elementi sono stati aggiunti o solo un sottoinsieme e il risultato mostra all'utente finale che cosa effettivamente accade.

Quindi penso che l'intestazione Location non sia utilizzabile in tale contesto. Vedo due opzioni per il codice di stato:

• Il codice di stato è se è stato creato almeno un elemento)
• Il codice di stato è per dire che la richiesta di maggior esito positivo a livello globale, ma la il risultato di ciascuna operazione è descritto nel contenuto della risposta.

Si può tuttavia notare che un codice di stato 202 esiste se la risorsa gestisce le creazioni di massa in modo asincrono. Ma nel contesto, è necessario quindi estrarre una risorsa per ottenere lo stato degli inserti.

Per quanto riguarda il contenuto della risposta, sei libero di scegliere. Potremmo immaginare una cosa del genere:

{ 
"took": 4, 
"errors": true | false, 
"items": [ 
    { "added": true, 
    "error": null 
    "id": "123" 
    }, 
    { "added": false, 
    "error": { 
     "code": "err12", 
     "description": "validation error (field type, ...)" 
    } 
    "id": null 
    } 
    ] 
} 

elasticsearch fornisce tale API di massa con creare, ma anche aggiornare ed eliminare il supporto - vedere questo link per maggiori informazioni: http://www.elastic.co/guide/en/elasticsearch/guide/current/bulk.html.

Qui ci sono domande simili che potrebbero dare alcuni suggerimenti:

• How to Update a REST Resource Collection
• REST API - Bulk Create or Update in single request

Spero che ti aiuta, Thierry