Nella programmazione in stile RESTful, dovremmo usare i metodi HTTP come elementi costitutivi. Sono un po 'confuso, tuttavia, quali metodi corrispondono ai classici metodi CRUD. GET / Read e DELETE / Delete sono abbastanza ovvi.
Tuttavia, qual è la differenza tra PUT / POST? Corrispondono uno a uno con Crea e Aggiorna?
Risposte:
Create = PUT with a new URI
POST to a base URI returning a newly created URI
Read = GET
Update = PUT with an existing URI
Delete = DELETE
PUT può essere mappato su Crea e Aggiorna in base all'esistenza dell'URI utilizzato con il PUT.
Mappe POST da creare.
Correzione: POST può anche essere mappato su Aggiorna sebbene sia generalmente utilizzato per Crea. Il POST può anche essere un aggiornamento parziale, quindi non è necessario il metodo PATCH proposto.
L'intera chiave è se stai facendo un cambiamento idempotente o no. Cioè, se agire due volte sul messaggio comporterà la "stessa" cosa come se fosse stata fatta una sola volta, hai una modifica idempotente e dovrebbe essere mappata su PUT. In caso contrario, esegue il mapping a POST. Se non si consente mai al client di sintetizzare gli URL, PUT è abbastanza vicino ad Update e POST può gestire Crea bene, ma questo non è certamente l'unico modo per farlo; se il cliente sa che vuole creare /foo/abce sa quale contenuto mettere lì, funziona perfettamente come PUT.
La descrizione canonica di un POST è quando ti impegni ad acquistare qualcosa: è un'azione che nessuno vuole ripetere senza saperlo. Al contrario, impostare in anticipo l'indirizzo di spedizione per l'ordine può essere fatto con PUT: non importa se ti viene chiesto di inviare 6 Anywhere Dr, Nowherevilleuna, due o cento volte: è sempre lo stesso indirizzo. Significa che si tratta di un aggiornamento? Potrebbe essere ... Tutto dipende da come si desidera scrivere il back-end. (Si noti che i risultati potrebbero non essere identici: è possibile riferire all'utente quando hanno eseguito un PUT l'ultima volta come parte della rappresentazione della risorsa, il che garantirebbe che i PUT ripetuti non causino un risultato identico, ma il risultato sarebbe comunque essere "lo stesso" in senso funzionale.)
POSTed PUTè interessante e dovrebbe dare la risposta a "Qual è 'create' e qual è 'update'?" molto più chiaro. Inoltre, per quanto riguarda l'implementazione dell'API, ne conseguirebbe che un ripetitivo PUTdovrebbe equivalere a un no-op silenzioso, mentre un ripetitivo POSTpotrebbe generare un'eccezione se alcuni aspetti dei dati inviati dovrebbero rimanere unici nell'archivio dati che supporta l'applicazione.
C'è un ottimo video di YouTube su Stormpath che in realtà spiega questo, l'URL dovrebbe saltare alla parte corretta del video:
Inoltre vale la pena guardare è più di un'ora di conversazione ma molto interessante se stai pensando di investire tempo nella costruzione di un API REST.
In questo momento (2016) gli ultimi verbi HTTP sono GET, POST, PATCH , PUT e DELETE
Panoramica
Spero che questo ti aiuti!
Se sei interessato a progettare API REST, questa è una lettura ansewome da avere! repository github versione online del sito web
Dipende dalla situazione concreta .. ma in generale:
PUT = aggiorna o modifica una risorsa concreta con un URI concreto della risorsa.
POST = crea una nuova risorsa sotto l'origine dell'URI specificato.
ie
Modifica un post sul blog:
PUT: / blog / entry / 1
Creane uno nuovo:
POST: / blog / entry
PUT può creare una nuova risorsa in alcune circostanze in cui l'URI della nuova risorsa è chiaro prima della richiesta. POST può essere utilizzato anche per implementare diversi altri casi d'uso, che non sono coperti dagli altri (GET, PUT, DELETE, HEAD, OPTIONS)
La comprensione generale per i sistemi CRUD è GET = request, POST = create, Put = update, DELETE = delete
I blocchi costitutivi di REST sono principalmente le risorse (e URI) e l'ipermedia. In questo contesto, GETè il modo di ottenere una rappresentazione della risorsa (che può effettivamente essere mappata SELECTin termini CRUD).
Tuttavia, non dovresti necessariamente aspettarti un mapping uno a uno tra operazioni CRUD e verbi HTTP. La differenza principale tra PUTe POSTriguarda la loro proprietà idempotente. POSTè anche più comunemente usato per aggiornamenti parziali, comePUT genere implica l'invio di una nuova rappresentazione completa della risorsa.
Suggerirei di leggere questo:
La specifica HTTP è anche un riferimento utile:
Il metodo PUT richiede che l'entità inclusa sia archiviata nell'URI di richiesta fornito.
[...]
La differenza fondamentale tra le richieste POST e PUT si riflette nel diverso significato dell'URI di richiesta. 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,
In generale, questo è lo schema che uso:
Il progetto Symfony cerca di mantenere uniti i suoi metodi HTTP con i metodi CRUD e il loro elenco li associa come segue:
Vale la pena notare che, come si dice in quella pagina, "In realtà, molti browser moderni non supportano i metodi PUT e DELETE".
Da quello che ricordo, Symfony "simula" PUT e DELETE per quei browser che non li supportano durante la generazione dei suoi moduli, al fine di provare ad avvicinarsi all'utilizzo del metodo HTTP teoricamente corretto anche quando un browser non supporta esso.