PUT vs. POST in REST

Totale:

Sia PUT che POST possono essere usati per creare.

Dovete chiedere "a cosa state eseguendo l'azione? " per distinguere cosa dovreste usare. Supponiamo che tu stia progettando un'API per fare domande. Se volete usare POST allora lo farete su una lista di domande. Se volete usare PUT allora lo farete per una particolare domanda.

Entrambi possono essere usati, quindi quale dovrei usare nel mio design RESTful:

Non è necessario supportare sia PUT che POST.

Quello che viene usato è lasciato a voi. Ma ricordatevi di usare quello giusto a seconda dell'oggetto a cui fate riferimento nella richiesta.

Alcune considerazioni:

• Date un nome ai vostri oggetti URL che create esplicitamente, o lasciate che sia il server a decidere? Se li nominate, allora usate PUT. Se lasciate che sia il server a decidere, allora usate POST.
• PUT è idempotente, quindi se si PUT un oggetto due volte, non ha effetto. Questa è una bella proprietà, quindi userei PUT quando possibile.
• Potete aggiornare o creare una risorsa con PUT con lo stesso URL dell'oggetto
• Con POST si possono avere 2 richieste che arrivano allo stesso tempo facendo modifiche ad un URL, e possono aggiornare parti diverse dell'oggetto.

Un esempio:

Ho scritto quanto segue come parte di un'altra risposta su SO riguardo a questo:

POST:

Usato per modificare e aggiornare una risorsa

POST /questions/ HTTP/1.1 Host: www.example.com/

Nota che il seguente è un errore:

POST /questions/ HTTP/1.1 Host: www.example.com/

Se l'URL non è ancora creato, tu non dovresti usare POST per crearlo mentre specifichi il nome. Questo dovrebbe risultare in un 'risorsa non trovata' errore perché non esiste ancora. Si dovrebbe PUTARE la sul server prima.

{\an8}(*Risorsa che non esiste.) Potresti però fare qualcosa come questo per creare una risorsa usando POST:

POST /domande HTTP/1.1 Host: www.example.com/

Si noti che in questo caso la risorsa non è specificato, i nuovi oggetti percorso dell'URL verrebbe restituito all'utente.

PUT:

usato per creare una risorsa, o sovrascriverla. Mentre si specifica il nuovo URL della risorsa.

per una nuova risorsa:

PUT /questions/ HTTP/1.1 Host: www.example.com/

Per sovrascrivere una risorsa esistente:

PUT /questions/ HTTP/1.1 Host: www.example.com/

Usate POST per creare e PUT per aggiornare. Questo è il modo in cui Ruby on Rails lo fa, comunque.

PUT    /items/1      #=> update
POST   /items        #=> create

REST è un concetto molto di alto livello. In effetti, non menziona nemmeno HTTP!

Se avete dubbi su come implementare REST in HTTP, potete sempre dare un'occhiata alla specifica Atom Publication Protocol (AtomPub). AtomPub è uno standard per scrivere webservices RESTful con HTTP che è stato sviluppato da molti luminari di HTTP e REST, con alcuni input di Roy Fielding, l'inventore di REST e (co-)inventore di HTTP stesso.

In effetti, potresti anche essere in grado di usare AtomPub direttamente. Sebbene sia venuto fuori dalla comunità dei blog, non è in alcun modo limitato ai blog: è un protocollo generico per interagire in modo REST con collezioni arbitrarie (annidate) di risorse arbitrarie via HTTP. Se potete rappresentare la vostra applicazione come una collezione annidata di risorse, allora potete semplicemente usare AtomPub e non preoccuparvi se usare PUT o POST, quali codici di stato HTTP restituire e tutti questi dettagli.

Questo è ciò che AtomPub ha da dire sulla creazione delle risorse (sezione 9.2):

Per aggiungere membri ad una Collection, i client inviano richieste POST all'URI della Collection.