Secondo le specifiche HTTP / 1.1:

Il POSTmetodo viene utilizzato per richiedere che il server di origine accetta l'entità racchiusa nella richiesta come nuova subordinata della risorsa identificata dal Request-URInelRequest-Line

In altre parole, POSTviene utilizzato per creare .

Il PUTmetodo richiede che l'entità racchiusa sia archiviata sotto quella fornita Request-URI. Se si Request-URIriferisce a una risorsa già esistente, l'entità inclusa DOVREBBE essere considerata come una versione modificata di quella residente sul server di origine. Se Request-URInon punta a una risorsa esistente e quell'URI è in grado di essere definito come una nuova risorsa dall'agente utente richiedente, il server di origine può creare la risorsa con quell'URI. "

Cioè, PUTviene utilizzato per creare o sostituire .

Quindi, quale dovrebbe essere usato per creare una risorsa? O è necessario supportare entrambi?

Complessivamente:

Sia PUT che POST possono essere utilizzati per la creazione.

Devi chiedere "a che cosa stai eseguendo l'azione?" per distinguere cosa dovresti usare. Supponiamo che tu stia progettando un'API per porre domande. Se si desidera utilizzare POST, è necessario farlo in un elenco di domande. Se vuoi usare PUT, lo faresti per una domanda particolare.

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

Non è necessario supportare sia PUT che POST.

Chi viene usato è lasciato a te. Ma ricorda di usare quello giusto in base all'oggetto a cui fai riferimento nella richiesta.

Alcune considerazioni:

• Dai un nome agli oggetti URL che crei esplicitamente o lasci che il server decida? Se li chiami, usa PUT. Se si lascia decidere al server, utilizzare POST.
• PUT è idempotente, quindi se metti un oggetto due volte, non ha alcun effetto. Questa è una bella proprietà, quindi vorrei usare PUT quando possibile.
• È possibile aggiornare o creare una risorsa con PUT con lo stesso URL oggetto
• Con POST è possibile ricevere 2 richieste contemporaneamente apportando modifiche a un URL e possono aggiornare diverse parti dell'oggetto.

Un esempio:

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

INVIARE:

Utilizzato per modificare e aggiornare una risorsa

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Si noti che quanto segue è un errore:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

Se l'URL non è ancora stato creato, non dovresti utilizzare POST per crearlo mentre specifichi il nome. Ciò dovrebbe comportare un errore "risorsa non trovata" perché <new_question>non esiste ancora. Dovresti prima mettere la <new_question> risorsa sul server.

Potresti però fare qualcosa del genere per creare risorse usando POST:

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

Si noti che in questo caso il nome della risorsa non è specificato, il percorso URL dei nuovi oggetti verrebbe restituito.

METTERE:

Utilizzato per creare una risorsa o sovrascriverla. Mentre specifichi le risorse nuovo URL.

Per una nuova risorsa:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

Per sovrascrivere una risorsa esistente:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Inoltre, e un po 'più concisamente, RFC 7231 Sezione 4.3.4 PUT afferma (enfasi aggiunta),

4.3.4. METTERE

Il metodo PUT richiede che lo stato della risorsa di destinazione sia createdo replacedcon lo stato definito dalla rappresentazione racchiusa nel payload del messaggio di richiesta.

Puoi trovare affermazioni sul Web che dicono

• POST dovrebbe essere usato per creare una risorsa e PUT dovrebbe essere usato per modificarne una
• PUT dovrebbe essere usato per creare una risorsa e POST dovrebbe essere usato per modificarne una

Nessuno dei due ha ragione.

Meglio scegliere tra PUT e POST in base all'idempotenza dell'azione.

PUT implica mettere una risorsa, sostituendo completamente tutto ciò che è disponibile nell'URL specificato con una cosa diversa. Per definizione, un PUT è idempotente. Fallo tutte le volte che vuoi e il risultato è lo stesso. x=5è idempotente. Puoi mettere una risorsa se esiste in precedenza o meno (ad esempio, per creare o aggiornare)!

POST aggiorna una risorsa, aggiunge una risorsa sussidiaria o provoca una modifica. Un POST non è idempotente, nel modo in cui x++non è idempotente.

Con questo argomento, PUT serve a creare quando conosci l'URL della cosa che creerai. POST può essere utilizzato per creare quando si conosce l'URL della "fabbrica" ​​o del gestore per la categoria di cose che si desidera creare.

così:

POST /expense-report

o:

PUT  /expense-report/10929

• POST a un URL crea una risorsa figlio in un URL definito dal server .
• MESSA a un URL crea / sostituisce la risorsa nella sua interezza nell'URL definito dal client .
• PATCH su un URL aggiorna parte della risorsa nell'URL definito dal client.

La specifica pertinente per PUT e POST è RFC 2616 §9.5ff.

POST crea una risorsa figlio , quindi POST /itemscrea una risorsa che vive sotto la /itemsrisorsa. Per esempio. /items/1. L'invio due volte dello stesso pacchetto postale creerà due risorse.

PUT serve per creare o sostituire una risorsa in un URL conosciuto dal client .

Pertanto: PUT è solo un candidato per CREATE in cui il client conosce già l'URL prima della creazione della risorsa. Per esempio. /blogs/nigel/entry/when_to_use_post_vs_putpoiché il titolo viene utilizzato come chiave di risorsa

PUT sostituisce la risorsa all'URL noto se esiste già, quindi l'invio della stessa richiesta due volte non ha alcun effetto. In altre parole, le chiamate a PUT sono idempotenti .

L'RFC legge così:

La differenza fondamentale tra le richieste POST e PUT si riflette nel diverso significato di Request-URI. L'URI in una richiesta POST identifica la risorsa che gestirà l'entità chiusa. Tale risorsa potrebbe essere un processo di accettazione dei dati, un gateway verso qualche altro protocollo o un'entità separata che accetta le annotazioni. Al contrario, l'URI in una richiesta PUT identifica l'entità racchiusa nella richiesta: l'agente utente sa cosa è destinato l'URI e il server NON DEVE tentare di applicare la richiesta ad altre risorse. Se il server desidera che la richiesta venga applicata a un URI diverso,

Nota: PUT è stato principalmente utilizzato per aggiornare le risorse (sostituendole nella loro interezza), ma recentemente si è spostato verso l'utilizzo di PATCH per l'aggiornamento delle risorse esistenti, poiché PUT specifica che sostituisce l'intera risorsa. RFC 5789.

Aggiornamento 2018 : esiste un caso che può essere fatto per evitare PUT. Vedi "RESTO senza PUT"

Con la tecnica "REST senza PUT", l'idea è che i consumatori siano costretti a pubblicare nuove risorse di richiesta "nominate". Come discusso in precedenza, la modifica dell'indirizzo postale di un cliente è un POST in una nuova risorsa "ChangeOfAddress", non un PUT di una risorsa "Cliente" con un valore di campo dell'indirizzo postale diverso.

tratto da REST API Design - Resource Modeling di Prakash Subramaniam di Thoughtworks

Ciò impone all'API di evitare problemi di transizione dello stato con più client che aggiornano una singola risorsa e si abbina più facilmente con il sourcing degli eventi e il CQRS. Quando il lavoro viene eseguito in modo asincrono, POSTARE la trasformazione e attendere che venga applicata sembra appropriato.

Sommario:

Creare:

Può essere eseguito con PUT o POST nel modo seguente:

METTERE

Crea IL nuova risorsa con newResourceId come identificatore, sotto le risorse / URI, o di raccolta .

PUT /resources/<newResourceId> HTTP/1.1 

INVIARE

Crea una nuova risorsa sotto l'URI / risorse o raccolta . Di solito l'identificatore viene restituito dal server.

POST /resources HTTP/1.1

Aggiornare:

Può essere eseguito solo con PUT nel modo seguente:

METTERE

Aggiorna la risorsa con esistenteResourceId come identificatore, sotto l'URI / resources o raccolta .

PUT /resources/<existingResourceId> HTTP/1.1

Spiegazione:

Quando hai a che fare con REST e URI in generale, hai generici a sinistra e specifici a destra . I generici sono generalmente chiamati raccolte e gli elementi più specifici possono essere chiamati risorse . Si noti che una risorsa può contenere una raccolta .

Esempi:

<- generico - specifico ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

Quando usi POST ti riferisci sempre a una raccolta , quindi ogni volta che dici:

POST /users HTTP/1.1

stai pubblicando un nuovo utente nella raccolta utenti .

Se vai avanti e prova qualcosa del genere:

POST /users/john HTTP/1.1

funzionerà, ma semanticamente stai dicendo che vuoi aggiungere una risorsa alla raccolta john sotto la raccolta utenti .

Una volta che si utilizza PUT, ci si riferisce a una risorsa o a un singolo elemento, possibilmente all'interno di una raccolta . Quindi quando dici:

PUT /users/john HTTP/1.1

stai dicendo all'aggiornamento del server o crea, se non esiste, la risorsa john nella raccolta utenti .

Spec:

Vorrei evidenziare alcune parti importanti delle specifiche:

INVIARE

Il metodo POST viene utilizzato per richiedere che il server di origine accetti l'entità racchiusa nella richiesta come nuovo subordinato della risorsa identificata dall'URI di richiesta nella riga di richiesta

Quindi, crea una nuova risorsa in una raccolta .

METTERE

Il metodo PUT richiede che l'entità inclusa sia archiviata nell'URI di richiesta fornito. Se l'URI della richiesta fa riferimento a una risorsa già esistente , l'entità inclusa DOVREBBE essere considerata come una versione modificata di quella residente sul server di origine. Se l'URI di richiesta non punta a una risorsa esistente e tale URI può essere definito come una nuova risorsa dall'agente utente richiedente, il server di origine può creare la risorsa con tale URI. "

Quindi, creare o aggiornare in base all'esistenza della risorsa .

Riferimento:

• Specifica HTTP / 1.1
• Wikipedia - REST
• Uniform Resource Identifier (URI): sintassi e semantica generiche

POST significa "crea nuovo" come in "Ecco l'input per la creazione di un utente, crealo per me".

PUT significa "inserisci, sostituisci se esiste già" come in "Ecco i dati per l'utente 5".

È possibile POSTad esempio.com/utente poiché non si conosce URLancora l'utente, si desidera che il server lo crei.

È PUTpossibile example.com/users/id poiché si desidera sostituire / creare un utente specifico .

POSTARE due volte con gli stessi dati significa creare due utenti identici con ID diversi. Mettere due volte con gli stessi dati crea il primo utente e lo aggiorna allo stesso stato la seconda volta (nessuna modifica). Dal momento che alla fine PUTsi ottiene lo stesso stato, non importa quante volte lo si esegue, si dice che sia "ugualmente potente" ogni volta - idempotente. Questo è utile per riprovare automaticamente le richieste. Non più "sei sicuro di voler inviare nuovamente" quando premi il pulsante Indietro sul browser.

Un consiglio generale è da utilizzare POSTquando è necessario che il server abbia il controllo della URLgenerazione delle risorse. Utilizzare PUTaltrimenti. Preferisco PUT finita POST.

Vorrei aggiungere il mio consiglio "pragmatico". Utilizzare PUT quando si conosce "id" con cui è possibile recuperare l'oggetto che si sta salvando. L'uso di PUT non funzionerà troppo bene se, ad esempio, è necessario un ID generato dal database da restituire per eseguire ricerche o aggiornamenti futuri.

Quindi: per salvare un utente esistente o uno in cui il client genera l'id ed è stato verificato che l'id è univoco:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

In caso contrario, utilizzare POST per creare inizialmente l'oggetto e PUT per aggiornare l'oggetto:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

Usa POST per creare e PUT per aggiornare. È così che lo fa Ruby on Rails.

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

Entrambi sono usati per la trasmissione dei dati tra client e server, ma ci sono sottili differenze tra loro, che sono:

Analogia:

• Metti cioè prendi e metti dove era.
• POST come posta inviare posta ufficio.

Analogia sui social media / rete:

• Post sui social media: quando pubblichiamo un messaggio, crea un nuovo post.
• Inserisci (cioè modifica) per il messaggio che abbiamo già pubblicato.

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

Se hai dei dubbi su come implementare REST in HTTP, puoi sempre dare un'occhiata alla specifica Atom Publication Protocol (AtomPub) . AtomPub è uno standard per la scrittura di servizi Web RESTful con HTTP sviluppato da molti luminari HTTP e REST, con alcuni input di Roy Fielding, l'inventore di REST e (co) inventore dello stesso HTTP.

In effetti, potresti persino essere in grado di utilizzare direttamente AtomPub. Mentre è uscito dalla comunità dei blog, non è in alcun modo limitato ai blog: è un protocollo generico per interagire RESTAMENTE con raccolte arbitrarie (nidificate) di risorse arbitrarie tramite HTTP. Se puoi rappresentare la tua applicazione come una raccolta nidificata di risorse, puoi semplicemente usare AtomPub e non preoccuparti se usare PUT o POST, quali codici di stato HTTP restituire e tutti quei dettagli.

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

Per aggiungere membri a una raccolta, i client inviano richieste POST all'URI della raccolta.

La decisione se utilizzare PUT o POST per creare una risorsa su un server con un'API HTTP + REST si basa su chi possiede la struttura dell'URL. Avere il cliente a conoscenza o partecipare alla definizione, la struttura dell'URL è un accoppiamento non necessario affine agli accoppiamenti indesiderati che sono sorti dalla SOA. La fuga di tipi di giunti è la ragione per cui REST è così popolare. Pertanto, il metodo corretto da utilizzare è POST. Esistono eccezioni a questa regola e si verificano quando il client desidera mantenere il controllo sulla struttura della posizione delle risorse distribuite. Questo è raro e probabilmente significa che qualcos'altro è sbagliato.

A questo punto alcune persone sostengono che se si utilizzano RESTful-URL , il client conosce l'URL della risorsa e quindi un PUT è accettabile. Dopotutto, questo è il motivo per cui gli URL canonici, normalizzati, Ruby on Rails, Django sono importanti, guarda l'API di Twitter ... blah blah blah. Quelle persone devono capire che non esiste un URL Restful e che lo stesso Roy Fielding afferma che :

Un'API REST non deve definire nomi o gerarchie di risorse fisse (un ovvio accoppiamento di client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Consentire invece ai server di istruire i clienti su come costruire URI appropriati, ad esempio nei moduli HTML e nei modelli URI, definendo tali istruzioni all'interno dei tipi di media e delle relazioni di collegamento. [Il fallimento qui implica che i clienti stanno assumendo una struttura di risorse a causa di informazioni fuori banda, come uno standard specifico del dominio, che è l'equivalente orientato ai dati all'accoppiamento funzionale di RPC].

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

L'idea di un RESTful-URL è in realtà una violazione di REST in quanto il server è responsabile della struttura dell'URL e dovrebbe essere libero di decidere come usarlo per evitare l'accoppiamento. Se questo ti confonde, leggi il significato dell'auto-scoperta sul design dell'API.

L'uso di POST per creare risorse comporta una considerazione progettuale perché POST non è idempotente. Ciò significa che ripetere più volte un POST non garantisce lo stesso comportamento ogni volta. Questo spaventa le persone a usare PUT per creare risorse quando non dovrebbero. Sanno che è sbagliato (POST è per CREATE) ma lo fanno comunque perché non sanno come risolvere questo problema. Questa preoccupazione è dimostrata nella seguente situazione:

1. Il client POST una nuova risorsa sul server.
2. Il server elabora la richiesta e invia una risposta.
3. Il client non riceve mai la risposta.
4. Il server non è a conoscenza del client non ha ricevuto la risposta.
5. Il client non ha un URL per la risorsa (quindi PUT non è un'opzione) e ripete il POST.
6. Il POST non è idempotente e il server ...

Il passaggio 6 è dove le persone sono confuse su cosa fare. Tuttavia, non esiste alcun motivo per creare un kludge per risolvere questo problema. Invece, HTTP può essere utilizzato come specificato in RFC 2616 e il server risponde:

10.4.10 409 Conflitto

Impossibile completare la richiesta a causa di un conflitto con lo stato corrente della risorsa. Questo codice è consentito solo nelle situazioni in cui è previsto che l'utente possa essere in grado di risolvere il conflitto e inviare nuovamente la richiesta. Il corpo di risposta DOVREBBE includere abbastanza

informazioni affinché l'utente possa riconoscere l'origine del conflitto. Idealmente, l'entità di risposta dovrebbe includere informazioni sufficienti per l'utente o l'agente utente per risolvere il problema; tuttavia, ciò potrebbe non essere possibile e non è necessario.

È più probabile che si verifichino conflitti in risposta a una richiesta PUT. Ad esempio, se si utilizzava il controllo delle versioni e l'entità in fase di PUT includeva modifiche a una risorsa in conflitto con quelle fatte da una richiesta precedente (di terze parti), il server potrebbe utilizzare la risposta 409 per indicare che non è possibile completare la richiesta . In questo caso, l'entità della risposta conterrebbe probabilmente un elenco delle differenze tra le due versioni in un formato definito dal Content-Type di risposta.

Rispondere con un codice di stato di 409 Conflict è il ricorso corretto perché :

• L'esecuzione di un POST di dati che ha un ID che corrisponde a una risorsa già nel sistema è "un conflitto con lo stato corrente della risorsa".
• Poiché la parte importante è che il client capisca che il server ha la risorsa e che intraprende le azioni appropriate. Questa è una "situazione / e in cui si prevede che l'utente possa essere in grado di risolvere il conflitto e inviare nuovamente la richiesta".
• Una risposta che contiene l'URL della risorsa con l'ID in conflitto e le condizioni preliminari appropriate per la risorsa fornirebbe "informazioni sufficienti per l'utente o l'agente utente per risolvere il problema", che è il caso ideale per RFC 2616.

Aggiornamento basato sul rilascio di RFC 7231 per sostituire 2616

RFC 7231 è progettato per sostituire 2616 e nella Sezione 4.3.3 descrive la seguente possibile risposta per un POST

Se il risultato dell'elaborazione di un POST equivale a una rappresentazione di una risorsa esistente, un server di origine può reindirizzare l'agente utente a tale risorsa inviando una risposta 303 (Vedi altro) con l'identificatore della risorsa esistente nel campo Posizione. Ciò ha i vantaggi di fornire all'agente utente un identificatore di risorse e di trasferire la rappresentazione tramite un metodo più suscettibile alla memorizzazione nella cache condivisa, sebbene a costo di una richiesta aggiuntiva se l'agente utente non ha già la rappresentazione memorizzata nella cache.

Ora potrebbe essere allettante restituire semplicemente un 303 nel caso in cui venga ripetuto un POST. Comunque, l'opposto è vero. Restituire un 303 avrebbe senso solo se più richieste di creazione (creazione di risorse diverse) restituiscono lo stesso contenuto. Un esempio potrebbe essere un "grazie per aver inviato il messaggio di richiesta" che il client non deve scaricare nuovamente ogni volta. RFC 7231 sostiene ancora nella sezione 4.2.2 che il POST non deve essere idempotente e continua a sostenere che il POST dovrebbe essere usato per creare.

Per ulteriori informazioni a riguardo, leggi questo articolo .

Mi piace questo consiglio, dalla definizione di PUT di RFC 2616 :

La differenza fondamentale tra le richieste POST e PUT si riflette nel diverso significato di Request-URI. L'URI in una richiesta POST identifica la risorsa che gestirà l'entità chiusa. Tale risorsa potrebbe essere un processo di accettazione dei dati, un gateway verso qualche altro protocollo o un'entità separata che accetta le annotazioni. Al contrario, l'URI in una richiesta PUT identifica l'entità racchiusa nella richiesta: l'agente utente sa cosa è destinato l'URI e il server NON DEVE tentare di applicare la richiesta ad altre risorse.

Questo è in contrasto con gli altri consigli qui, che PUT è meglio applicato alle risorse che hanno già un nome e POST è buono per creare un nuovo oggetto sotto una risorsa esistente (e lasciare che il server lo assegni).

Interpreto questo e i requisiti di idempotenza su PUT, nel senso che:

• POST è utile per creare nuovi oggetti in una raccolta (e creare non deve essere idempotente)
• PUT è buono per l'aggiornamento di oggetti esistenti (e l'aggiornamento deve essere idempotente)
• Il POST può anche essere utilizzato per aggiornamenti non idempotenti di oggetti esistenti (in particolare, cambiare parte di un oggetto senza specificare tutto - se ci pensi, la creazione di un nuovo membro di una raccolta è in realtà un caso speciale di questo tipo di aggiornamento, dal punto di vista della collezione)
• PUT può essere utilizzato anche per creare se e solo se si consente al client di assegnare un nome alla risorsa. Ma dal momento che i client REST non dovrebbero fare ipotesi sulla struttura degli URL, questo è meno nello spirito previsto delle cose.

In breve:

PUT è idempotente, in cui lo stato della risorsa sarà lo stesso se la stessa operazione viene eseguita una volta o più volte.

POST è non idempotente, in cui lo stato della risorsa può variare se l'operazione viene eseguita più volte rispetto all'esecuzione una sola volta.

Analogia con query di database

PUT Puoi pensare a "UPDATE STUDENT SET address =" abc "dove id =" 123 ";

POST Puoi pensare a qualcosa come "INSERT INTO STUDENT (nome, indirizzo) VALUES (" abc "," xyzzz ");

L'ID studente viene generato automaticamente.

Con PUT, se la stessa query viene eseguita più volte o una volta, lo stato della tabella STUDENT rimane lo stesso.

In caso di POST, se la stessa query viene eseguita più volte, vengono creati più record Student nel database e lo stato del database cambia ad ogni esecuzione di una query "INSERT".

NOTA: PUT ha bisogno di un percorso di risorse (già risorsa) su cui deve avvenire l'aggiornamento, mentre POST non lo richiede. Pertanto POST intuitivamente è pensato per la creazione di una nuova risorsa, mentre PUT è necessario per l'aggiornamento della risorsa già esistente.

Alcuni potrebbero pensare che gli aggiornamenti possano essere eseguiti con POST. Non esiste una regola rigida quale utilizzare per gli aggiornamenti o quale creare per creare. Anche in questo caso si tratta di convenzioni e intuitivamente sono propenso al ragionamento sopra menzionato e lo seguo.

POST è come pubblicare una lettera in una casella di posta o pubblicare un'e-mail in una coda di posta elettronica. PUT è come quando metti un oggetto in un buco cubby o un posto su uno scaffale (ha un indirizzo noto).

Con POST, stai postando all'indirizzo della CODA o della COLLEZIONE. Con PUT, ti stai rivolgendo all'indirizzo dell'ITEM.

PUT è idempotente. Puoi inviare la richiesta 100 volte e non importa. Il POST non è idempotente. Se invii la richiesta 100 volte, riceverai 100 e-mail o 100 lettere nella tua casella postale.

Una regola generale: se conosci l'id o il nome dell'articolo, usa PUT. Se si desidera che l'id o il nome dell'articolo vengano assegnati dalla parte ricevente, utilizzare POST.

Nuova risposta (ora che ho capito meglio REST):

PUT è semplicemente una dichiarazione del contenuto che il servizio dovrebbe, d'ora in poi, utilizzare per rendere rappresentazioni della risorsa identificata dal client; POST è una dichiarazione del contenuto che il servizio dovrebbe, d'ora in poi, contenere (possibilmente duplicato) ma spetta al server come identificarlo.

PUT x(se xidentifica una risorsa ): "Sostituisci il contenuto della risorsa identificato da xcon il mio contenuto."

PUT x(se xnon identifica una risorsa): "Crea una nuova risorsa contenente il mio contenuto e usalo xper identificarlo."

POST x: "Conserva il mio contenuto e dammi un identificatore che posso usare per identificare una risorsa (vecchia o nuova) contenente tale contenuto (possibilmente mescolata con altro contenuto). Detta risorsa dovrebbe essere identica o subordinata a quella che xidentifica." " La risorsa di y è subordinata alla risorsa di x " è tipicamente ma non necessariamente implementata trasformando in y un sottotraccia di x (ad es. x = /fooe y = /foo/bar) e modificando la rappresentazione o le rappresentazioni della risorsa di x per riflettere l'esistenza di una nuova risorsa, ad esempio con un collegamento ipertestuale a yrisorsa e alcuni metadati. Solo quest'ultimo è davvero essenziale per una buona progettazione, poiché gli URL sono opachi in REST - dovresti usare hypermedia invece della costruzione di URL sul lato client per attraversare comunque il servizio.

In REST non esiste una risorsa contenente "contenuto". Mi riferisco come "contenuto" ai dati che il servizio utilizza per rendere le rappresentazioni in modo coerente. In genere è costituito da alcune righe correlate in un database o in un file (ad esempio un file di immagine). Spetta al servizio convertire il contenuto dell'utente in qualcosa che il servizio può utilizzare, ad esempio convertendo un payload JSON in istruzioni SQL.

Risposta originale (potrebbe essere più facile da leggere) :

PUT /something(se /somethingesiste già): "Prendi quello che hai /somethinge sostituiscilo con quello che ti do."

PUT /something(se /somethingnon esiste già): "Prendi ciò che ti do e mettilo a /something."

POST /something: "Prendi quello che ti do e mettilo dove vuoi /somethingfino a quando mi dai il suo URL quando hai finito."

Risposta breve:

Semplice regola empirica: utilizzare POST per creare, utilizzare PUT per l'aggiornamento.

Risposta lunga:

INVIARE:

• POST viene utilizzato per inviare dati al server.
• Utile quando l'URL della risorsa è sconosciuto

METTERE:

• PUT viene utilizzato per trasferire lo stato sul server
• Utile quando è noto l'URL di una risorsa

Risposta più lunga:

Per capirlo, dobbiamo chiederci perché fosse richiesto il PUT, quali fossero i problemi che il PUT stava cercando di risolvere e che il POST non ha potuto risolvere.

Dal punto di vista di un'architettura REST non c'è nulla che conta. Avremmo potuto vivere anche senza PUT. Ma dal punto di vista dello sviluppatore di un cliente ha reso la sua vita molto più semplice.

Prima di PUT, i client non erano in grado di conoscere direttamente l'URL generato dal server o se tutto ciò ne avesse generato o se i dati da inviare al server fossero già aggiornati o meno. PUT ha sollevato lo sviluppatore di tutti questi mal di testa. PUT è idempotente, PUT gestisce le condizioni di gara e PUT consente al client di scegliere l'URL.

Ruby on Rails 4.0 utilizzerà il metodo "PATCH" anziché PUT per eseguire aggiornamenti parziali.

RFC 5789 dice di PATCH (dal 1995):

È necessario un nuovo metodo per migliorare l'interoperabilità e prevenire errori. Il metodo PUT è già definito per sovrascrivere una risorsa con un nuovo corpo completo e non può essere riutilizzato per apportare modifiche parziali. Altrimenti, i proxy e le cache, e anche i client e i server, potrebbero confondersi sul risultato dell'operazione. Il POST è già utilizzato ma senza ampia interoperabilità (per uno, non esiste un modo standard per scoprire il supporto del formato patch). PATCH era menzionato nelle specifiche HTTP precedenti, ma non completamente definito.

" Edge Rails: PATCH è il nuovo metodo HTTP primario per gli aggiornamenti ", spiega.

A rischio di riaffermare ciò che è già stato detto, sembra importante ricordare che PUT implica che il client controlla ciò che l' URL finirà per essere, durante la creazione di una risorsa. Quindi parte della scelta tra PUT e POST riguarderà quanto puoi fidarti del client per fornire URL corretti e normalizzati coerenti con qualunque sia il tuo schema URL.

Quando non puoi fidarti completamente del client per fare la cosa giusta, sarebbe più appropriato usare POST per creare un nuovo elemento e quindi inviare l'URL al client nella risposta.

In un modo molto semplice sto prendendo l'esempio della sequenza temporale di Facebook.

Caso 1: quando pubblichi qualcosa sulla tua cronologia, si tratta di una nuova voce nuova. Quindi in questo caso usano il metodo POST perché il metodo POST non è idempotente.

Caso 2: se il tuo amico commenta il tuo post per la prima volta, anche questo creerà una nuova voce nel database in modo da utilizzare il metodo POST.

Caso 3: se il tuo amico modifica il suo commento, in questo caso, aveva un ID commento, quindi aggiornerà un commento esistente invece di creare una nuova voce nel database. Pertanto per questo tipo di operazione utilizzare il metodo PUT perché è idempotente. *

In una sola riga, utilizzare POST per aggiungere una nuova voce nel database e PUT per aggiornare qualcosa nel database.

La considerazione più importante è l' affidabilità . Se si perde un messaggio POST, lo stato del sistema non è definito. Il recupero automatico è impossibile. Per i messaggi PUT, lo stato non è definito solo fino al primo tentativo riuscito.

Ad esempio, potrebbe non essere una buona idea creare transazioni con carta di credito con POST.

Se ti capita di avere URI generati automaticamente sulla tua risorsa, puoi comunque usare PUT passando un URI generato (che punta a una risorsa vuota) al client.

Alcune altre considerazioni:

• POST invalida le copie memorizzate nella cache dell'intera risorsa contenente (migliore coerenza)
• Le risposte PUT non sono memorizzabili nella cache mentre quelle POST (Richiedi contenuto-posizione e scadenza)
• PUT è meno supportato ad esempio da Java ME, browser meno recenti, firewall

I lettori che non conoscono questo argomento saranno colpiti dalla discussione infinita su cosa dovresti fare e dalla relativa assenza di lezioni dall'esperienza. Il fatto che il REST sia "preferito" rispetto al SOAP è, suppongo, un apprendimento di alto livello dall'esperienza, ma per fortuna dobbiamo essere progrediti da lì? È il 2016. La tesi di dottorato di Roy è stata nel 2000. Cosa abbiamo sviluppato? Era divertente? È stato facile integrarsi con? Supportare? Gestirà l'ascesa di smartphone e connessioni mobili traballanti?

Secondo ME, le reti della vita reale non sono affidabili. Timeout delle richieste. Le connessioni vengono ripristinate. Le reti si interrompono per ore o giorni alla volta. I treni entrano nei tunnel con gli utenti mobili a bordo. Per ogni data richiesta (come occasionalmente riconosciuto in tutta questa discussione) la richiesta può cadere nell'acqua sulla sua strada, oppure la risposta può cadere nell'acqua sulla via del ritorno. In queste condizioni, l'invio di richieste PUT, POST e DELETE direttamente contro risorse sostanziali mi ha sempre sembrato un po 'brutale e ingenuo.

HTTP non fa nulla per garantire il completamento affidabile della richiesta-risposta, e va bene perché questo è correttamente il lavoro delle applicazioni sensibili alla rete. Sviluppando una tale applicazione, puoi saltare attraverso i cerchi per usare PUT invece di POST, quindi più cerchi per dare un certo tipo di errore sul server se rilevi richieste duplicate. Di nuovo al cliente, devi saltare attraverso i cerchi per interpretare questi errori, recuperare, riconvalidare e ripubblicare.

Oppure puoi farlo : considera le tue richieste non sicure come risorse effimere per singolo utente (chiamiamole azioni). I clienti richiedono una nuova "azione" su una risorsa sostanziale con un POST vuoto alla risorsa. POST verrà utilizzato solo per questo. Una volta in modo sicuro in possesso dell'URI dell'azione appena coniata, il client METTE la richiesta non sicura all'URI dell'azione, non la risorsa di destinazione . Risolvere l'azione e aggiornare la risorsa "reale" è correttamente il lavoro dell'API ed è qui disaccoppiato dalla rete inaffidabile.

Il server svolge l'attività, restituisce la risposta e la memorizza rispetto all'URI dell'azione concordato . Se qualcosa va storto, il client ripete la richiesta (comportamento naturale!) E se il server l'ha già vista, ripete la risposta memorizzata e non fa nient'altro .

Individuerai rapidamente la somiglianza con le promesse: creiamo e restituiamo il segnaposto per il risultato prima di fare qualsiasi cosa. Anche come una promessa, un'azione può avere successo o fallire una volta, ma il suo risultato può essere recuperato ripetutamente.

Soprattutto, diamo la possibilità di inviare e ricevere applicazioni per collegare l'azione identificata in modo univoco all'unicità nei rispettivi ambienti. E possiamo iniziare a chiedere e far rispettare! Comportamento responsabile dei clienti: ripeti le tue richieste quanto vuoi, ma non andare a generare una nuova azione finché non sei in possesso di un risultato definitivo da quello esistente.

Pertanto, numerosi problemi spinosi scompaiono. Le richieste di inserimento ripetute non creano duplicati e non creiamo la vera risorsa finché non siamo in possesso dei dati. (le colonne del database possono rimanere non annullabili). Le richieste di aggiornamento ripetute non colpiranno stati incompatibili e non sovrascriveranno le modifiche successive. I clienti possono (ri) recuperare ed elaborare senza problemi la conferma originale per qualsiasi motivo (client bloccato, risposta mancante, ecc.).

Le richieste di eliminazione successive possono visualizzare ed elaborare la conferma originale, senza colpire un errore 404. Se le cose impiegano più tempo del previsto, possiamo rispondere in via provvisoria e abbiamo un posto dove il cliente può ricontrollare per il risultato definitivo. La parte più bella di questo modello è la sua proprietà Kung-Fu (Panda). Prendiamo un punto debole, la propensione per i clienti a ripetere una richiesta ogni volta che non capiscono la risposta e la trasformiamo in un punto di forza :-)

Prima di dirmi che questo non è RESTful, ti preghiamo di considerare i numerosi modi in cui i principi REST sono rispettati. I clienti non costruiscono URL. L'API rimane rilevabile, sebbene con un piccolo cambiamento nella semantica. I verbi HTTP sono usati in modo appropriato. Se pensi che questo sia un cambiamento enorme da implementare, posso dirti per esperienza che non lo è.

Se pensi di avere enormi quantità di dati da archiviare, parliamo di volumi: una tipica conferma di aggiornamento è una frazione di un kilobyte. HTTP ti dà attualmente un minuto o due per rispondere in modo definitivo. Anche se memorizzi azioni solo per una settimana, i clienti hanno ampie possibilità di recuperare. Se si dispone di volumi molto elevati, è possibile che si desideri un archivio valori chiave dedicato conforme agli acidi o una soluzione in memoria.

Oltre alle differenze suggerite da altri, voglio aggiungerne uno in più.

Nel metodo POST è possibile inviare i parametri del corpo inform-data

Nel metodo PUT devi inviare i parametri del corpox-www-form-urlencoded

Intestazione Content-Type:application/x-www-form-urlencoded

Di conseguenza, non è possibile inviare file o dati multipart nel metodo PUT

MODIFICARE

Il tipo di contenuto "application / x-www-form-urlencoded" non è efficace per l'invio di grandi quantità di dati binari o testo contenente caratteri non ASCII. Il tipo di contenuto "multipart / form-data" deve essere utilizzato per l'invio di moduli che contengono file, dati non ASCII e dati binari.

Ciò significa che devi inviare

file, dati non ASCII e dati binari

dovresti usare il metodo POST

Sembra esserci sempre un po 'di confusione su quando utilizzare il POST HTTP rispetto al metodo PUT HTTP per i servizi REST. La maggior parte degli sviluppatori proverà ad associare le operazioni CRUD direttamente ai metodi HTTP. Sosterrò che questo non è corretto e non si può semplicemente associare i concetti CRUD ai metodi HTTP. Questo è:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

È vero che R (etrieve) e D (elete) delle operazioni CRUD possono essere mappati direttamente ai metodi HTTP GET e DELETE rispettivamente. Tuttavia, la confusione sta nelle operazioni C (reate) e U (update). In alcuni casi, è possibile utilizzare il PUT per una creazione, mentre in altri casi sarà richiesto un POST. L'ambiguità sta nella definizione di un metodo PUT HTTP rispetto a un metodo POST HTTP.

Secondo le specifiche HTTP 1.1, i metodi GET, HEAD, DELETE e PUT devono essere idempotenti e il metodo POST non è idempotente. Vale a dire che un'operazione è idempotente se può essere eseguita su una risorsa una o più volte e restituire sempre lo stesso stato di quella risorsa. Considerando che un'operazione non idempotente può restituire uno stato modificato della risorsa da una richiesta all'altra. Quindi, in un'operazione non idempotente, non vi è alcuna garanzia che si riceverà lo stesso stato di una risorsa.

Sulla base della definizione idempotente di cui sopra, la mia opinione sull'uso del metodo HTTP PUT rispetto all'utilizzo del metodo HTTP POST per i servizi REST è: Utilizzare il metodo HTTP PUT quando:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

In entrambi i casi, queste operazioni possono essere eseguite più volte con gli stessi risultati. Cioè la risorsa non verrà modificata richiedendo l'operazione più di una volta. Quindi, una vera operazione idempotente. Utilizzare il metodo POST HTTP quando:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

Conclusione

Non correlare direttamente e mappare le operazioni CRUD ai metodi HTTP per i servizi REST. L'uso di un metodo PUT HTTP rispetto a un metodo POST HTTP dovrebbe essere basato sull'aspetto idempotente di tale operazione. Cioè, se l'operazione è idempotente, utilizzare il metodo HTTP PUT. Se l'operazione non è idempotente, utilizzare il metodo POST HTTP.

il server di origine può creare la risorsa con quell'URI

Quindi usi POST e probabilmente, ma non necessario, PUT per la creazione di risorse. Non devi supportare entrambi. Per me il POST è perfettamente perfetto. Quindi è una decisione di progettazione.

Come indicato nella citazione, si utilizza PUT per la creazione di una risorsa non assegnata a un IRI e si desidera comunque creare una risorsa. Ad esempio, di PUT /users/123/passwordsolito sostituisce la vecchia password con una nuova, ma è possibile utilizzarla per creare una password se non esiste già (ad esempio, da utenti appena registrati o ripristinando utenti vietati).

Atterrerò con il seguente:

PUT si riferisce a una risorsa, identificata dall'URI. In questo caso, lo stai aggiornando. È la parte dei tre verbi che si riferiscono alle risorse: cancella e diventa gli altri due.

POST è fondamentalmente un messaggio in formato libero, con il suo significato definito "fuori banda". Se il messaggio può essere interpretato come l'aggiunta di una risorsa a una directory, sarebbe OK, ma in pratica è necessario comprendere il messaggio che si sta inviando (postare) per sapere cosa accadrà con la risorsa.

Poiché PUT, GET e DELETE si riferiscono a una risorsa, sono anche per definizione idempotenti.

POST può svolgere le altre tre funzioni, ma la semantica della richiesta andrà persa sugli intermediari come cache e proxy. Questo vale anche per fornire sicurezza sulla risorsa, poiché l'URI di un post non indica necessariamente la risorsa a cui si sta applicando (può però).

Un PUT non deve necessariamente essere un creare; il servizio potrebbe errori se la risorsa non è già stata creata, ma in caso contrario aggiornarla. O viceversa: può creare la risorsa, ma non consentire aggiornamenti. L'unica cosa richiesta per PUT è che punta a una risorsa specifica e il suo payload è la rappresentazione di quella risorsa. Un PUT riuscito significa (escludendo l'interferenza) che un GET recuperi la stessa risorsa.

Modifica: un'altra cosa - un PUT può creare, ma se lo fa, l'ID deve essere un ID naturale - AKA un indirizzo e-mail. In questo modo quando metti due volte, il secondo put è un aggiornamento del primo. Questo lo rende idempotente .

Se viene generato l'ID (un nuovo ID dipendente, ad esempio), il secondo PUT con lo stesso URL creerebbe un nuovo record, il che viola la regola idempotente. In questo caso il verbo sarebbe POST e il messaggio (non risorsa) sarebbe quello di creare una risorsa usando i valori definiti in questo messaggio.

La semantica dovrebbe essere diversa, in quanto "PUT", come "GET", dovrebbe essere idempotente - il che significa che puoi richiedere la stessa richiesta PUT più volte e il risultato sarà come se l'avessi eseguita una sola volta.

Descriverò le convenzioni che ritengo siano le più utilizzate e le più utili:

Quando inserisci una risorsa in un determinato URL, ciò che accade è che deve essere salvato in quell'URL o qualcosa del genere.

Quando pubblichi una risorsa in corrispondenza di un determinato URL, spesso pubblichi un'informazione relativa a tale URL. Ciò implica che la risorsa nell'URL esiste già.

Ad esempio, quando si desidera creare un nuovo flusso, è possibile inserirlo in qualche URL. Ma quando vuoi POST un messaggio a uno stream esistente, POST al suo URL.

Per quanto riguarda la modifica delle proprietà dello stream, puoi farlo con PUT o POST. Fondamentalmente, usa "PUT" solo quando l'operazione è idempotente, altrimenti usa POST.

Si noti, tuttavia, che non tutti i browser moderni supportano verbi HTTP diversi da GET o POST.

Il più delle volte li userete in questo modo:

• POST una risorsa in una raccolta
• PUT una risorsa identificata da collection /: id

Per esempio:

• POST / articoli
• PUT / items / 1234

In entrambi i casi, il corpo della richiesta contiene i dati per la risorsa da creare o aggiornare. Dovrebbe essere ovvio dai nomi delle rotte che POST non è idempotente (se lo chiamate 3 volte creerà 3 oggetti), ma PUT è idempotente (se lo chiamate 3 volte il risultato è lo stesso). PUT viene spesso utilizzato per l'operazione "upsert" (creazione o aggiornamento), ma è sempre possibile restituire un errore 404 se si desidera utilizzarlo solo per modificarlo.

Si noti che POST "crea" un nuovo elemento nella raccolta e PUT "sostituisce" un elemento in un determinato URL, ma è una pratica molto comune utilizzare PUT per modifiche parziali, ovvero utilizzarlo solo per aggiornare le risorse esistenti e modifica solo i campi inclusi nel corpo (ignorando gli altri campi). Ciò è tecnicamente errato, se si desidera essere puristi di REST, PUT dovrebbe sostituire l'intera risorsa e utilizzare PATCH per l'aggiornamento parziale. Personalmente non mi interessa molto nella misura in cui il comportamento è chiaro e coerente su tutti i tuoi endpoint API.

Ricorda, REST è un insieme di convenzioni e linee guida per rendere semplice la tua API. Se si finisce con un aggirare complicato solo per selezionare la casella "RESTfull", allora si sta sconfiggendo lo scopo;)

Sebbene esista probabilmente un modo agnostico per descriverli, sembra essere in conflitto con varie dichiarazioni dalle risposte ai siti Web.

Siamo molto chiari e diretti qui. Se sei uno sviluppatore .NET che lavora con l'API Web, i fatti sono (dalla documentazione dell'API Microsoft), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -api-that-supporta-crud-operazioni :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

Sicuramente "puoi" usare "POST" per l'aggiornamento, ma segui semplicemente le convenzioni stabilite per te con la tua struttura. Nel mio caso è .NET / Web API, quindi PUT è per AGGIORNAMENTO non c'è dibattito.

Spero che questo aiuti tutti gli sviluppatori Microsoft che leggono tutti i commenti con i collegamenti ai siti Web Amazon e Sun / Java.

Ecco una semplice regola:

PUT to a URL dovrebbe essere usato per aggiornare o creare la risorsa che può essere localizzata a quell'URL.

Il POST di un URL deve essere utilizzato per aggiornare o creare una risorsa che si trova su un altro URL ("subordinato") o che non è localizzabile tramite HTTP.

Se hai familiarità con le operazioni del database, ci sono

1. Selezionare
2. Inserire
3. Aggiornare
4. Elimina
5. Unisci (aggiorna se già esistente, altrimenti inserisci)

Uso PUTper Unisci e aggiorno come operazioni e utilizzo POSTper Inserimenti.

In pratica, POST funziona bene per la creazione di risorse. L'URL della risorsa appena creata deve essere restituito nell'intestazione della risposta della posizione. PUT dovrebbe essere usato per aggiornare completamente una risorsa. Si prega di comprendere che queste sono le migliori pratiche durante la progettazione di un'API RESTful. Le specifiche HTTP in quanto tali non limitano l'utilizzo di PUT / POST con alcune restrizioni per la creazione / l'aggiornamento delle risorse. Dai un'occhiata a http://techoctave.com/c7/posts/71-twitter-rest-api-dissected che sintetizza le migliori pratiche.