Perché abbiamo bisogno di qualcosa di più di HTTP GET, PUT, POST?

Question

Qual è il vantaggio pratico dell'utilizzo di HTTP GET, PUT, DELETE, POST, HEAD? Perché non concentrarsi sui loro benefici comportamentali (sicurezza e idempotenza), dimenticare i loro nomi e usare GET, PUT o POST a seconda del comportamento che vogliamo?

Perché non dovremmo usare solo GET, PUT e POST (e rilasciare HEAD, DELETE)?

Answer 1

L'approccio [REST] [1] utilizza POST, GET, PUT e DELETE per implementare le regole CRUD per una risorsa web. È un modo semplice e ordinato per esporre oggetti alle richieste sul Web. Sono i servizi web senza spese generali.

Giusto per chiarire le differenze semantiche. Ogni operazione è piuttosto diversa. Il punto è avere simpatici metodi HTTP che abbiano significati chiari e distinti.

POST crea nuovi oggetti. L'URI non ha chiave; accetta un corpo di messaggio che definisce l'oggetto. Inserisci SQL. [ Modifica Sebbene non ci siano motivi tecnici per cui POST non abbia una chiave, la gente REST suggerisce fortemente che POST abbia un significato distinto come CREATE, non dovrebbe avere una chiave.]

GET recupera oggetti esistenti. L'URI può avere una chiave, dipende dal fatto che tu stia facendo GET singleton o che faccia la lista GET. SQL Select

PUT aggiorna un oggetto esistente. L'URI ha una chiave; Accetta un corpo del messaggio che aggiorna un oggetto. Aggiornamento SQL.

DELETE elimina un oggetto esistente. L'URI ha una chiave. Elimina SQL.

È possibile aggiornare un record con POST anziché PUT? Non senza introdurre qualche ambiguità. I verbi dovrebbero avere effetti inequivocabili. Inoltre, gli URI POST non hanno chiave, dove PUT deve avere una chiave.

Quando POSSO, mi aspetto un 201 CREATO. Se non capisco, c'è qualcosa che non va. Allo stesso modo, quando metto, mi aspetto un 200 OK. Se non capisco, qualcosa non va.

Suppongo che potresti insistere su qualche ambiguità in cui POST fa POST o PUT. L'URI deve essere diverso; anche il messaggio associato potrebbe essere diverso. In genere, le persone REST prendono spunto da SQL dove INSERT e UPDATE sono verbi diversi.

Potresti pensare che UPDATE debba essere inserito se il record non esiste o aggiornato se il record esiste. Tuttavia, è più semplice se AGGIORNAMENTO significa AGGIORNAMENTO e il mancato aggiornamento indica che qualcosa non va. Un segreto di ritorno a INSERT rende l'operazione ambigua.

Se non stai costruendo un'interfaccia RESTful, è tipico usare GET e POST solo per recuperare e creare / aggiornare. È comune avere differenze URI o differenze nel contenuto dei messaggi per distinguere tra POST e PUT quando una persona fa clic su Invia su un modulo. Tuttavia, non è molto pulito perché il codice deve determinare se sei nel POST = create case o POST = update case.

Answer 2

POST non ha garanzie di safety o idempotency . Questo è uno dei motivi per PUT e DELETE : entrambi PUT e DELETE sono idempotenti (ovvero 1 + N richieste identiche hanno lo stesso risultato finale di una sola richiesta).

PUT viene utilizzato per impostare lo stato di una risorsa in un determinato URI. Quando invii una POST a una risorsa in un determinato URI, quella risorsa non deve essere sostituita dal soddisfare. Al massimo, dovrebbe essere aggiunto a. Questo è il motivo per cui il POST non è idempotente: in caso di aggiunta di POSTS, ogni richiesta verrà aggiunta alla risorsa (ad esempio, pubblicare ogni volta un nuovo in un forum di discussione).

DELETE viene utilizzato per assicurarsi che una risorsa in un determinato URI venga rimossa dal server. POST non dovrebbe normalmente essere utilizzato per l'eliminazione, tranne nel caso di invio di una richiesta di eliminazione. Ancora una volta, l'URI della risorsa a cui si POSTARE in quel caso non dovrebbe essere l'URI per la risorsa che si desidera eliminare. Qualsiasi risorsa per la quale si POST è una risorsa che accetta i dati POST da aggiungere a se stessa, aggiungere a una raccolta o elaborare in qualche altro modo.

HEAD viene utilizzato se tutto ciò che ti interessa sono le intestazioni di una richiesta GET e non vuoi sprecare la larghezza di banda sul contenuto effettivo. È bello avere.

Answer 3

Perché abbiamo bisogno di più del POST? Consente ai dati di fluire in entrambi i modi, quindi perché GET sarebbe necessario? La risposta è sostanzialmente la stessa della tua domanda. Standardizzando le aspettative di base dei vari metodi, altri processi possono sapere meglio cosa fare.

Ad esempio, i proxy di memorizzazione nella cache possono avere maggiori possibilità di fare la cosa giusta.

Pensa ad HEAD per esempio. Se il server proxy sa cosa significa HEAD, può elaborare il risultato di una precedente richiesta GET per fornire la risposta corretta a una richiesta HEAD. E può sapere che POST, PUT e DELETE non devono essere memorizzati nella cache.

Answer 4

Nessuno ha pubblicato il tipo di risposta che stavo cercando, quindi cercherò di riassumere i punti da solo.

" Servizi Web RESTful " capitolo 8 sezione "Sovraccarico POST" dice: " Se vuoi fare a meno di PUT e DELETE del tutto, è del tutto RESTOSO esporre operazioni sicure sulle risorse tramite GET e tutte le altre operazioni tramite POST sovraccarico. In questo modo si viola la mia architettura orientata alle risorse, ma è conforme alle regole meno restrittive di REST. & Quot;

In breve, la sostituzione di PUT / DELETE a favore di POST rende l'API più difficile da leggere e le chiamate PUT / DELETE non sono più idempotenti .

Answer 5

In una parola:

idempotenza

In poche parole:

OTTIENI = sicuro + idempotente

PUT = idempotent

DELETE = idempotent

POST = né sicuro né idempotente

'Idempotent' significa solo che puoi farlo più e più volte e farà sempre esattamente la stessa cosa.

Puoi riemettere una richiesta PUT (aggiornamento) o ELIMINA tutte le volte che vuoi e avrà lo stesso effetto ogni volta, tuttavia l'effetto desiderato modificherà una risorsa in modo che non sia considerato "sicuro".

Una richiesta POST dovrebbe creare una nuova risorsa con ogni richiesta, il che significa che l'effetto sarà diverso ogni volta. Pertanto il POST non è considerato sicuro o idempotente.

Metodi come GET e HEAD sono solo operazioni di lettura e sono quindi considerati "sicuri" come idempotenti.

Questo è in realtà un concetto abbastanza importante perché fornisce un modo standard / coerente per interpretare le transazioni HTTP; questo è particolarmente utile in un contesto di sicurezza.

Answer 6

Non tutti gli hoster non supportano PUT, DELETE.

Ho fatto questa domanda, in un mondo ideale avremmo tutti i verbi ma ....:

Servizi web RESTful e verbi HTTP

Answer 7

HEAD è davvero utile per determinare su che cosa è impostato l'orologio di un determinato server (preciso entro 1 secondo o il tempo di andata e ritorno della rete, a seconda di quale sia maggiore). È anche ottimo per ottenere citazioni di Futurama da Slashdot:

~$ curl -I slashdot.org
HTTP/1.1 200 OK
Date: Wed, 29 Oct 2008 05:35:13 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001227
X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank.
Cache-Control: private
Pragma: private
Connection: close
Content-Type: text/html; charset=iso-8859-1

Per cURL , -I è l'opzione per eseguire una richiesta HEAD . Per ottenere la data e l'ora correnti di un determinato server, basta fare

arricciatura -I $ server | grep ^ Data

Answer 8

Limitare l'ambiguità che consentirà un riutilizzo migliore / più semplice delle nostre semplici API REST.

Answer 9

Potresti usare solo GET e POST, ma perdi un po 'della precisione e della chiarezza offerte da PUT e DELETE. POST è un'operazione con caratteri jolly che potrebbe significare qualsiasi cosa. Il comportamento di PUT e DELETE è molto ben definito. Se si pensa a un'API di gestione delle risorse, GET, PUT e DELETE probabilmente coprono l'80% -90% della funzionalità richiesta. Se ti limiti a OTTENERE e POST, accedi al 40% -60% della tua API usando il POST mal specificato.

Answer 10

Le applicazioni Web che utilizzano GET e POST consentono agli utenti di creare, visualizzare, modificare ed eliminare i propri dati, ma a un livello superiore ai comandi HTTP originariamente creati per questi scopi. Una delle idee alla base di REST è un ritorno all'intento originale del design del Web, in base al quale esistono operazioni HTTP specifiche per ciascun verbo CRUD.

Inoltre, il comando HEAD può essere utilizzato per migliorare l'esperienza dell'utente per download di file (potenzialmente di grandi dimensioni). Chiama HEAD per scoprire quanto sarà grande la risposta e quindi chiama GET per recuperare effettivamente il contenuto.

Answer 11

Vedi il seguente link per un esempio illustrativo. Suggerisce anche un modo per utilizzare il metodo http OPTIONS, che non è ancora stato discusso qui.

Answer 12

Esistono estensioni http come WebDAV che richiedono funzionalità aggiuntive.

http://en.wikipedia.org/wiki/WebDAV

Answer 13

Probabilmente la guerra del web server dei giorni precedenti lo ha causato.

In HTTP 1.0 scritto nel 1996, c'erano solo GET, HEAD e POST . Ma come puoi vedere in Appendice D , i venditori hanno iniziato ad aggiungere il loro cose proprie. Pertanto, per mantenere la compatibilità con HTTP, sono stati costretti a creare HTTP 1.1 nel 1999 .

  

Tuttavia, HTTP / 1.0 non tiene sufficientemente conto   gli effetti dei proxy gerarchici, la memorizzazione nella cache, la necessità di   connessioni permanenti o host virtuali. Inoltre, la proliferazione   di applicazioni implementate in modo incompleto che si autodefiniscono   & Quot; HTTP / 1.0 " ha richiesto una modifica della versione del protocollo per   due applicazioni comunicanti per determinare le vere capacità reciproche.

     

Questa specifica definisce il protocollo indicato come "HTTP / 1.1". Questo protocollo include requisiti più rigorosi di HTTP / 1.0 in ordine   per garantire un'attuazione affidabile delle sue funzionalità.

Answer 14

GET, PUT, DELETE e POST sono ritardi da un'era in cui i secondo anno pensavano che una pagina web potesse essere ridotta a pochi principi di gravità.

Al giorno d'oggi, la maggior parte delle pagine Web sono entità composite, che contengono alcune o tutte queste operazioni primitive. Ad esempio, una pagina potrebbe avere moduli per la visualizzazione o l'aggiornamento delle informazioni sui clienti, che forse comprende una serie di tabelle.

Di solito uso $ _REQUEST [] in php, non mi interessa davvero come sono arrivate le informazioni. Sceglierei di utilizzare i metodi GET o PUT basati sull'efficienza, non sui paradigmi (multipli) sottostanti.