REST - In che modo una richiesta PUT gestisce gli identificatori di risorse con incremento automatico

Question

Secondo HTTP 1.1. spec:

se la richiesta-URI non punta a una risorsa esistente, e che URI è in grado di essere definito come una nuova risorsa dal richiedente agente utente, il server di origine in grado di creare la risorsa con quella URI.

In altre parole, PUT può essere utilizzato per creare l'aggiornamento &. Più specificamente, se faccio una richiesta PUT, ad es.

PUT /users/1 

e che l'utente non esiste, mi aspetto che il risultato di questa richiesta crei un utente con questo ID. Tuttavia, come funzionerebbe se il tuo back-end utilizza una chiave di incremento automatico? Sarebbe un caso di ignorarlo semplicemente se non è fattibile (ad esempio auto-incremento è a 6 e richiedo 10) & creando se è possibile (ad esempio richiesta 7)?

Dallo snippet che ho estratto sopra sembra darti questa flessibilità, solo cercando qualche chiarimento.

Answer 1

Suggerirei di utilizzare POST, non PUT, per una chiave di incremento automatico o non utilizzare la chiave di incremento automatico nell'ID risorsa.

Se si utilizza il POST, quindi si POST a /users anziché a /users/1. La risposta potrebbe reindirizzare a /users/1 o qualunque sia l'ID.

Se si utilizza PUT, è possibile immettere su /users/10292829 dove il numero è una chiave risorsa univoca generata sul client. Questa chiave può essere generata nel tempo, oppure può essere un hash di tempo, ID di sessione e altri fattori per garantire l'unicità del valore nel pubblico del cliente. Il server può quindi generare il proprio indice autoincrementato, distinto da 10292829 o qualsiasi altra cosa.

Per ulteriori informazioni su questo, vedere PUT vs POST in REST

---

In seguito. . .

Nel caso di consentire PUT a/users/XXXXXXX, per tutti gli utenti, ci si ritroverà con due chiavi uniche distinte che fanno riferimento alla stessa risorsa. (10292829 e 1 potrebbero riferirsi allo stesso utente). Dovresti decidere come consentire l'uso di ciascuna di queste chiavi diverse in un URL in stile REST. A causa della necessità di riconciliare l'uso di questi due ID distinti, preferirei utilizzare la prima opzione, POSTing a /users e ottenere un URL REST univoco della risorsa creata nella risposta.

Ho appena riletto the relevant section of RFC 2616, e ho visto un codice di ritorno appositamente progettato per questo nelle applicazioni REST:

10.2.2 201 Creato

La richiesta è stata soddisfatta e ha provocato una nuova risorsa in fase di creazione. La risorsa appena creata può essere referenziata dagli URI restituiti nell'entità della risposta, con l'URI più specifico per la risorsa fornita da un campo dell'intestazione di posizione. La risposta DOVREBBE includere un'entità che contiene un elenco di caratteristiche di risorse e ubicazione (s) da cui l'utente o utente agente può scegliere quello più appropriato. Il formato dell'entità è specificato dal tipo di media indicato nel campo dell'intestazione Content-Type.Il server di origine DEVE creare la risorsa prima di restituire il codice di stato 201. Se l'azione non può essere eseguita immediatamente, il server DOVREBBE rispondere con una risposta 202 (accettata).

Quindi, il modo RESTful per andare è nella quale inserire l'/users e restituire un 201 Created, con un colpo di testa Location: specificando /users/1.

Answer 2

Si dovrebbe utilizzare il POST per creare risorse mentre il PUT deve essere utilizzato solo per l'aggiornamento. In realtà la semantica REST ti obbliga a farlo.