Risposte:
PUT HTTP:
PUT inserisce un file o una risorsa in un URI specifico e esattamente in tale URI. Se esiste già un file o una risorsa in quell'URI, PUT sostituisce quel file o risorsa. Se non ci sono file o risorse lì, PUT ne crea uno. PUT è idempotente , ma paradossalmente le risposte PUT non sono memorizzabili nella cache.
Posizione RFC HTTP 1.1 per PUT
POST HTTP:
Il POST invia i dati a un URI specifico e si aspetta che la risorsa in tale URI gestisca la richiesta. Il web server a questo punto può determinare cosa fare con i dati nel contesto della risorsa specificata. Il metodo POST non è idempotente , tuttavia le risposte POST sono memorizzabili nella cache finché il server imposta le intestazioni Cache-Control appropriate e scade.
La RFC HTTP ufficiale specifica che POST è:
Posizione RFC HTTP 1.1 per POST
Differenza tra POST e PUT:
Lo stesso RFC spiega la differenza fondamentale:
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, DEVE inviare una risposta 301 (spostata in modo permanente); l'agente dell'utente PUO 'quindi prendere la propria decisione riguardo al reindirizzamento della richiesta.
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
createdoreplacedcon lo stato definito dalla rappresentazione racchiusa nel payload del messaggio di richiesta.
Utilizzando il metodo giusto, non correlato a parte:
Uno dei vantaggi di REST ROA vs SOAP è che quando si utilizza HTTP REST ROA, si incoraggia il corretto utilizzo dei verbi / metodi HTTP. Quindi, per esempio, useresti PUT solo quando desideri creare una risorsa in quella posizione esatta. E non useresti mai GET per creare o modificare una risorsa.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Quindi un'implementazione di PUT che rifiuta di creare una risorsa se non presente sarebbe corretta, giusto? In tal caso, ciò accade in pratica? O le implementazioni di solito creano anche su PUT?
Solo semantica.
Un HTTP PUTdovrebbe accettare il corpo della richiesta e quindi memorizzarlo nella risorsa identificata dall'URI.
Un HTTP POSTè più generale. Dovrebbe avviare un'azione sul server. Tale azione potrebbe essere quella di archiviare il corpo della richiesta nella risorsa identificata dall'URI o potrebbe essere un URI diverso o potrebbe essere un'azione diversa.
PUT è come un caricamento di file. Un put a un URI influenza esattamente quell'URI. Un POST a un URI potrebbe avere alcun effetto.
Per fornire esempi di risorse in stile REST:
"POST / libri" con un mucchio di informazioni sul libro potrebbe creare un nuovo libro e rispondere con il nuovo URL che identifica quel libro: "/ books / 5".
"PUT / books / 5" dovrebbe creare un nuovo libro con l'id 5 o sostituire il libro esistente con ID 5.
In stile senza risorse, il POST può essere utilizzato per qualsiasi cosa abbia un effetto collaterale. Un'altra differenza è che il PUT dovrebbe essere idempotente: più PUT degli stessi dati nello stesso URL dovrebbero andare bene, laddove più POST potrebbero creare più oggetti o qualunque cosa sia l'azione POST.
PUT è inteso come un metodo per "caricare" elementi in un URI particolare o per sovrascrivere ciò che è già in quell'URI.
Il POST, d'altra parte, è un modo per inviare dati CORRELATI a un dato URI.
Fare riferimento a HTTP RFC
Per quanto ne so, PUT viene utilizzato principalmente per aggiornare i record.
POST: per creare documenti o qualsiasi altra risorsa
PUT - Per aggiornare il documento creato o qualsiasi altra risorsa.
Ma per essere chiari su questo PUT di solito 'Sostituisce' il record esistente se è presente e crea se non è presente.
Altri hanno già pubblicato risposte eccellenti, volevo solo aggiungere che con la maggior parte delle lingue, dei framework e dei casi d'uso avrai a che fare con POST molto, molto più spesso di PUT. Al punto in cui PUT, DELETE, ecc. Sono fondamentalmente domande trivia.
Si prega di consultare: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Ultimamente sono stato piuttosto infastidito da un malinteso popolare da parte degli sviluppatori Web che un POST viene utilizzato per creare una risorsa e un PUT per aggiornarne / cambiarne una.
Se dai un'occhiata a pagina 55 di RFC 2616 ("Hypertext Transfer Protocol - HTTP / 1.1"), Sezione 9.6 ("PUT"), vedrai a cosa serve PUT:
Il metodo PUT richiede che l'entità inclusa sia archiviata nell'URI di richiesta fornito.
C'è anche un utile paragrafo per spiegare la differenza tra POST e PUT:
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.
Non menziona nulla sulla differenza tra aggiornamento / creazione, perché non è di questo che si tratta. Riguarda la differenza tra questo:
obj.set_attribute(value) # A POST request.
E questo:
obj.attribute = value # A PUT request.
Quindi, per favore, ferma la diffusione di questo malinteso popolare. Leggi i tuoi RFC.
Un POST è considerato una specie di metodo di fabbrica. Includete i dati con esso per creare ciò che volete e qualunque cosa si trovi dall'altra parte sa cosa farne. Un PUT viene utilizzato per aggiornare i dati esistenti in un determinato URL o per creare qualcosa di nuovo quando si sa quale sarà l'URI e non esiste già (al contrario di un POST che creerà qualcosa e restituirà un URL a se necessario).
REST chiede agli sviluppatori di utilizzare i metodi HTTP esplicitamente e in modo coerente con la definizione del protocollo. Questo principio di progettazione REST di base stabilisce un mapping uno a uno tra le operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) e metodi HTTP. Secondo questa mappatura:
• Per creare una risorsa sul server, utilizzare POST.
• Per recuperare una risorsa, utilizzare GET.
• Per modificare lo stato di una risorsa o per aggiornarla, utilizzare PUT.
• Per rimuovere o eliminare una risorsa, utilizzare ELIMINA.
Ulteriori informazioni: Servizi Web RESTful: le basi di IBM
Dovrebbe essere piuttosto semplice quando usare l'uno o l'altro, ma parole complesse sono fonte di confusione per molti di noi.
Utilizzare PUTquando si desidera modificare una singola risorsa che fa già parte della raccolta di risorse. PUTsostituisce la risorsa nella sua interezza. Esempio:PUT /resources/:resourceId
Sidenote: utilizzare PATCHse si desidera aggiornare una parte della risorsa.
POSTquando si desidera aggiungere una risorsa figlio in una raccolta di risorse. POST => /resourcesPUTper le operazioni di AGGIORNAMENTO .POSTper le operazioni CREATE .GET / company / reports => Ottieni tutti i report
GET / company / reports / {id} => Ottieni le informazioni del report identificate da "id"
POST / company / reports => Crea un nuovo report
PUT / company / reports / {id} => Aggiorna il segnala le informazioni identificate da "id"
PATCH / azienda / reports / {id} => Aggiorna una parte delle informazioni del report identificate da "id"
DELETE / company / reports / {id} => Elimina il report da "id"
La differenza tra POST e PUT è che PUT è idempotente, ciò significa che chiamare più volte la stessa richiesta PUT produrrà sempre lo stesso risultato (che non è un effetto collaterale), mentre d'altra parte, chiamare ripetutamente una richiesta POST potrebbe avere ( ulteriori) effetti collaterali della creazione della stessa risorsa più volte.
GET : Le richieste che utilizzano GET recuperano solo dati, ovvero richiedono una rappresentazione della risorsa specificata
POST: Invia i dati al server per creare una risorsa. Il tipo di corpo della richiesta è indicato dall'intestazione Content-Type. Spesso provoca un cambiamento di stato o effetti collaterali sul server
PUT : Crea una nuova risorsa o sostituisce una rappresentazione della risorsa di destinazione con il payload della richiesta
PATCH : Viene utilizzato per applicare modifiche parziali a una risorsa
DELETE : Elimina la risorsa specificata
TRACE : Esegue un test di loop-back dei messaggi lungo il percorso della risorsa di destinazione, fornendo un utile meccanismo di debug
OPTIONS : Viene utilizzato per descrivere le opzioni di comunicazione per la risorsa di destinazione, il client può specificare un URL per il metodo OPTIONS o un asterisco (*) per fare riferimento all'intero server.
HEAD : Richiede una risposta identica a quella di una richiesta GET, ma senza il corpo della risposta
CONNECT : Stabilisce un tunnel per il server identificato dalla risorsa di destinazione, può essere utilizzato per accedere a siti Web che utilizzano SSL (HTTPS)
Utilizzo conforme a REST
POST viene utilizzato per creare una nuova risorsa e quindi restituisce la risorsa URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Questa chiamata può creare un nuovo libro e restituire quel libro URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT viene utilizzato per sostituire una risorsa, se tale risorsa esiste, è sufficiente aggiornarla, ma se tale risorsa non esiste quindi crearla,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
Con PUTsappiamo l'identificatore di risorsa, ma POSTtornerà il nuovo identificatore di risorsa
Utilizzo non conforme a REST
POST viene utilizzato per avviare un'azione sul lato server, questa azione può o non può creare una risorsa, ma questa azione avrà effetti collaterali sempre cambierà qualcosa sul server
PUT viene utilizzato per posizionare o sostituire il contenuto letterale in un URL specifico
Un'altra differenza tra gli stili REST e non REST
POST è un'operazione non idempotente: causerà alcune modifiche se eseguita più volte con la stessa richiesta.
PUT è un'operazione idempotente: non avrà effetti collaterali se eseguito più volte con la stessa richiesta.
Vale la pena ricordare che POSTè soggetto ad alcuni comuni attacchi di contraffazione (CSRF) mentre PUTnon lo è.
Il CSRF di seguito non è possibile conPUT quando la vittima visita attackersite.com.
L' effetto dell'attacco è che la vittima, elimina involontariamente un utente solo perché (la vittima) è stato eseguito l'accesso come adminsu target.site.com, prima di visitare attackersite.com:
Richiesta normale (i cookie vengono inviati): ( PUTnon è un valore di attributo supportato)
Codice su attackersite.com:
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
Richiesta XHR (i cookie vengono inviati): ( PUTattiverà una richiesta di verifica preliminare, la cui risposta impedirebbe al browser di richiedere la deleteUserpagina)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
In parole semplici puoi dire:
1.HTTP Get: viene utilizzato per ottenere uno o più elementi
2.HTTP Post: viene utilizzato per creare un elemento
3.HTTP Put: è usato per aggiornare un oggetto
4.HTTP Patch: viene utilizzato per aggiornare parzialmente un elemento
5.HTTP Delete: viene utilizzato per eliminare un elemento
In realtà non c'è differenza se non il loro titolo. In realtà c'è una differenza di base tra GET e gli altri. Con un metodo "GET", richiedi i dati nella riga dell'indirizzo url, che vengono prima separati da un punto interrogativo, quindi con un segno &.
Ma con un metodo di richiesta "POST", non è possibile passare i dati attraverso l'URL, ma è necessario passare i dati come oggetto nel cosiddetto "corpo" della richiesta. Sul lato server, è quindi necessario leggere il corpo del contenuto ricevuto per ottenere i dati inviati. Ma dall'altra parte non c'è possibilità di inviare contenuti nel corpo, quando si invia una richiesta "OTTIENI".
L'affermazione che "GET" è solo per ottenere dati e "POST" per pubblicare dati è assolutamente sbagliata. Nessuno può impedirti di creare nuovi contenuti, eliminare contenuti esistenti, modificare contenuti esistenti o fare qualsiasi cosa nel backend, in base ai dati, che viene inviata dalla richiesta "GET" o dalla richiesta "POST". E nessuno può impedirti di codificare il backend in un certo senso, che con una richiesta "POST", il client richiede alcuni dati.
Con una richiesta, indipendentemente dal metodo utilizzato, si chiama un URL e si inviano o non si inviano alcuni dati per specificare, quali informazioni si desidera passare al server per gestire la richiesta, quindi il client riceve una risposta da il server. I dati possono contenere tutto ciò che si desidera inviare, al back-end è consentito fare qualsiasi cosa si desideri con i dati e la risposta può contenere tutte le informazioni che si desidera inserire.
Esistono solo questi due METODI DI BASE. OTTIENI e POST. Ma è la loro struttura, che li rende diversi e non ciò che codifichi nel back-end. Nel backend puoi codificare qualunque cosa tu voglia, con i dati ricevuti. Ma con la richiesta "POST" devi inviare / recuperare i dati nel corpo e non nella linea di indirizzi url, e con una richiesta "GET", devi inviare / recuperare i dati nella linea di indirizzi url e non in il corpo. È tutto.
Tutti gli altri metodi, come "PUT", "DELETE" e così via, hanno la stessa struttura di "POST".
Il metodo POST viene utilizzato principalmente, se si desidera nascondere un po 'il contenuto, poiché qualsiasi cosa si scriva nella linea di indirizzi url, questa verrà salvata nella cache e un metodo GET equivale a scrivere una linea di indirizzi url con i dati. Quindi, se si desidera inviare dati sensibili, che non sono sempre necessariamente nome utente e password, ma ad esempio alcuni ID o hash, che non si desidera vengano visualizzati nella riga dell'indirizzo url, è necessario utilizzare il metodo POST .
Anche la lunghezza della URL-Addressline è limitata a 1024 simboli, mentre il metodo "POST" non è limitato. Pertanto, se disponi di una maggiore quantità di dati, potresti non essere in grado di inviarli con una richiesta GET, ma dovrai utilizzare la richiesta POST. Quindi questo è anche un altro punto in più per la richiesta POST.
Ma gestire la richiesta GET è molto più semplice, quando non hai un testo complicato da inviare. Altrimenti, e questo è un altro punto a favore del metodo POST, è che con il metodo GET è necessario url codificare il testo, al fine di poter inviare alcuni simboli all'interno del testo o anche negli spazi. Ma con un metodo POST non hai restrizioni e il tuo contenuto non ha bisogno di essere modificato o manipolato in alcun modo.
Sia PUT che POST sono metodi di riposo.
PUT - Se facciamo la stessa richiesta due volte usando PUT usando gli stessi parametri entrambe le volte, la seconda richiesta non avrà alcun effetto. Questo è il motivo per cui PUT viene generalmente utilizzato per lo scenario di aggiornamento, chiamando Update più di una volta con gli stessi parametri non fa altro che la chiamata iniziale, quindi PUT è idempotente.
POST non è idempotente, ad esempio Crea creerà due voci separate nella destinazione, quindi non è idempotente, quindi CREATE è ampiamente utilizzato in POST.
Effettuare la stessa chiamata usando POST con gli stessi parametri ogni volta comporterà due cose diverse, quindi perché POST è comunemente usato per lo scenario Crea