Da quello che posso raccogliere, ci sono tre categorie:

1. Non usare GETe usare maiPOST
2. Non usare POSTe usare maiGET
3. Non importa quale usi.

Sono corretto nell'ipotesi di questi tre casi? In tal caso, quali sono alcuni esempi di ciascun caso?

Utilizzare POSTper azioni distruttive come la creazione (sono a conoscenza dell'ironia), la modifica e l'eliminazione, poiché non è possibile eseguire POSTun'azione nella barra degli indirizzi del browser. Utilizzare GETquando è sicuro consentire a una persona di chiamare un'azione. Quindi un URL come:

http://myblog.org/admin/posts/delete/357

Dovresti portarti a una pagina di conferma, piuttosto che semplicemente eliminare l'elemento. In questo modo è molto più semplice evitare incidenti.

POSTè anche più sicuro di GET, perché non stai inserendo informazioni in un URL. Quindi utilizzare GETcome methodper un modulo HTML che raccoglie una password o altre informazioni sensibili non è la migliore idea.

Un'ultima nota: POSTpuò trasmettere una quantità maggiore di informazioni rispetto a GET. 'POST' non ha limiti di dimensione per i dati trasmessi, mentre 'GET' è limitato a 2048 caratteri.

In breve

• Utilizzare GETper safe andidempotentrichieste
• Utilizzare POSTper neither safe nor idempotentrichieste

In dettaglio C'è un posto adatto per ciascuno. Anche se non segui i principi RESTful , si può ottenere molto imparando REST e come funziona un approccio orientato alle risorse.

Un'applicazione RESTful sarà use GETsper le operazioni che sono entrambe safe and idempotent.

Un'operazione safeè un'operazione che ha not change the datarichiesto.

Un'operazione idempotentè quella in cui il risultato be the samenon importa quante volte lo richiedi.

È ovvio che, poiché i GET vengono utilizzati per operazioni sicure , sono automaticamente anche idempotenti . In genere un GET viene utilizzato per recuperare una risorsa (ad esempio una domanda e le risposte associate su overflow dello stack) o la raccolta di risorse.

Un'app RESTful utilizzerà PUTsper le operazioni che lo sono not safe but idempotent.

So che la domanda riguardava GET e POST, ma tornerò al POST tra un secondo.

In genere un PUT viene utilizzato per modificare una risorsa (ad esempio, modificando una domanda o una risposta su overflow dello stack).

A POSTverrebbe utilizzato per qualsiasi operazione neither safe or idempotent.

In genere un POST verrebbe utilizzato per creare una nuova risorsa, ad esempio creando una NUOVA domanda SO (anche se in alcuni progetti un PUT verrebbe utilizzato anche per questo).

Se esegui il POST due volte finiresti per creare DUE nuove domande.

C'è anche un'operazione DELETE, ma suppongo di poterlo lasciare lì :)

Discussione

In termini pratici, i moderni browser Web supportano in genere solo GET e POST in modo affidabile (è possibile eseguire tutte queste operazioni tramite chiamate javascript, ma in termini di immissione dei dati nei moduli e premendo invio in genere sono disponibili le due opzioni). In un'applicazione RESTful il POST verrà spesso ignorato per fornire anche le chiamate PUT e DELETE.

Ma, anche se non stai seguendo i principi RESTful, può essere utile pensare in termini di utilizzo di GET per il recupero / visualizzazione delle informazioni e POST per la creazione / modifica delle informazioni.

Non dovresti mai usare GET per un'operazione che modifica i dati. Se un motore di ricerca esegue la ricerca per indicizzazione di un collegamento all'operazione malvagia o i segnalibri del client potrebbero comportare gravi problemi.

Usa GET se non ti dispiace che la richiesta venga ripetuta (ovvero non cambia stato).

Utilizzare POST se l'operazione modifica lo stato del sistema.

Versione breve

OTTIENI: solitamente utilizzato per le richieste di ricerca inviate o per qualsiasi richiesta in cui si desidera che l'utente sia in grado di recuperare nuovamente la pagina esatta.

Vantaggi di OTTENERE:

• Gli URL possono essere aggiunti ai segnalibri in modo sicuro.
• Le pagine possono essere ricaricate in modo sicuro.

Svantaggi di GET:

• Le variabili vengono passate attraverso l'URL come coppie nome-valore. (Rischio per la sicurezza)
• Numero limitato di variabili che possono essere passate. (Basato sul browser. Ad esempio, Internet Explorer ha un limite di 2.048 caratteri. )

POST: utilizzato per richieste di maggiore sicurezza in cui i dati possono essere utilizzati per modificare un database o una pagina che non si desidera aggiungere ai segnalibri.

Vantaggi del POST:

• Le coppie nome-valore non vengono visualizzate nell'URL. (Sicurezza + = 1)
• Il numero illimitato di coppie nome-valore può essere passato tramite POST. Riferimento.

Svantaggi di POST:

• La pagina che utilizzava dati POST non può essere segnalibro. (Se lo desideri).

Versione più lunga

Direttamente dal protocollo Hypertext Transfer - HTTP / 1.1 :

9.3 OTTIENI

Il metodo GET significa recuperare qualsiasi informazione (sotto forma di entità) identificata dall'URI di richiesta. Se l'URI della richiesta fa riferimento a un processo di produzione di dati, sono i dati prodotti che devono essere restituiti come entità nella risposta e non il testo di origine del processo, a meno che tale testo non sia l'output del processo.

La semantica del metodo GET cambia in un "GET condizionale" se il messaggio di richiesta include un campo di intestazione If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match o If-Range. Un metodo GET condizionale richiede che l'entità venga trasferita solo nelle circostanze descritte dai campi dell'intestazione condizionale. Il metodo GET condizionale ha lo scopo di ridurre l'utilizzo della rete non necessario consentendo l'aggiornamento delle entità memorizzate nella cache senza richiedere più richieste o trasferire dati già detenuti dal client.

La semantica del metodo GET cambia in un "GET parziale" se il messaggio di richiesta include un campo di intestazione Range. Un GET parziale richiede che venga trasferita solo una parte dell'entità, come descritto nella sezione 14.35. Il metodo GET parziale ha lo scopo di ridurre l'utilizzo della rete non necessario consentendo il completamento di entità parzialmente recuperate senza trasferire i dati già detenuti dal client.

La risposta a una richiesta GET è memorizzabile nella cache se e solo se soddisfa i requisiti per la memorizzazione nella cache HTTP descritti nella sezione 13.

Vedere la sezione 15.1.3 per considerazioni sulla sicurezza quando utilizzato per i moduli.

9.5 POST

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. POST è progettato per consentire a un metodo uniforme di coprire le seguenti funzioni:

• Annotazione di risorse esistenti;

• Pubblicare un messaggio su una bacheca, un newsgroup, una mailing list o un gruppo simile di articoli;

• Fornire un blocco di dati, come il risultato dell'invio di un modulo, a un processo di gestione dei dati;

• Estensione di un database tramite un'operazione di accodamento.

La funzione effettiva eseguita dal metodo POST è determinata dal server e di solito dipende dall'URI di richiesta. L'entità pubblicata è subordinata a tale URI nello stesso modo in cui un file è subordinato a una directory che lo contiene, un articolo di notizie è subordinato a un newsgroup in cui è pubblicato o un record è subordinato a un database.

L'azione eseguita dal metodo POST potrebbe non comportare una risorsa che può essere identificata da un URI. In questo caso, 200 (OK) o 204 (Nessun contenuto) è lo stato di risposta appropriato, a seconda che la risposta includa o meno un'entità che descrive il risultato.

La prima cosa importante è il significato di GET contro POST:

• GET dovrebbe essere usato per ... ottenere ... alcune informazioni dal server,
• mentre POST dovrebbe essere usato per inviare alcune informazioni al server.

Successivamente, un paio di cose che si possono notare:

• Utilizzando GET, i tuoi utenti possono utilizzare il pulsante "indietro" nel loro browser e possono aggiungere pagine ai segnalibri
• C'è un limite nella dimensione dei parametri che puoi passare come GET (2KB per alcune versioni di Internet Explorer, se non sbaglio) ; il limite è molto più per POST e generalmente dipende dalla configurazione del server.

Comunque, non penso che potremmo "vivere" senza GET: pensa a quanti URL stai usando con i parametri nella stringa di query, ogni giorno - senza GET, tutti quelli non funzionerebbero ;-)

Oltre alla differenza dei vincoli di lunghezza in molti browser Web, esiste anche una differenza semantica. I GET dovrebbero essere "sicuri" in quanto sono operazioni di sola lettura che non cambiano lo stato del server. I POST cambieranno di solito lo stato e forniranno avvisi in caso di reinvio. I web crawler dei motori di ricerca possono fare GET ma non dovrebbero mai fare POST.

Utilizzare GET se si desidera leggere i dati senza cambiare stato e utilizzare POST se si desidera aggiornare lo stato sul server.

La mia regola generale è di usare Get quando si effettuano richieste al server che non cambieranno stato. I post sono riservati per le richieste al server che modificano lo stato.

Una differenza pratica è che i browser e i server web hanno un limite al numero di caratteri che possono esistere in un URL. È diverso da un'applicazione all'altra, ma è certamente possibile colpirlo se hai textareadelle forme.

Un altro gotcha con GET: vengono indicizzati dai motori di ricerca e da altri sistemi automatici. Google una volta aveva un prodotto che avrebbe pre-recuperato i collegamenti sulla pagina che stavi visualizzando, quindi sarebbero più veloci da caricare se avessi fatto clic su quei collegamenti. Ha causato gravi danni in siti con collegamenti come delete.php?id=1: le persone hanno perso i loro interi siti.

Usa OTTIENI quando desideri che l'URL rifletta lo stato della pagina. Ciò è utile per visualizzare pagine generate dinamicamente, come quelle visualizzate qui. Un POST deve essere utilizzato in un modulo per inviare dati, come quando faccio clic sul pulsante "Pubblica la tua risposta". Produce anche un URL più pulito poiché non genera una stringa di parametri dopo il percorso.

Poiché i GET sono puramente URL, possono essere memorizzati nella cache dal browser Web e possono essere utilizzati meglio per cose come immagini generate in modo coerente. (Imposta un tempo di scadenza)

Un esempio dalla pagina gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET può generare prestazioni leggermente migliori, alcuni server web scrivono i contenuti POST in un file temporaneo prima di invocare il gestore.

Un'altra cosa da considerare è il limite di dimensioni. I GET sono limitati dalla dimensione dell'URL, 1024 byte dallo standard, anche se i browser possono supportare di più.

Il trasferimento di più dati di quelli dovrebbe utilizzare un POST per ottenere una migliore compatibilità del browser.

Anche meno di quel limite è un problema, come ha scritto un altro poster, qualsiasi cosa nell'URL potrebbe finire in altre parti dell'interfaccia utente del browser, come la storia.

Non c'è niente che tu non possa fare di per sé. Il punto è che non dovresti modificare lo stato del server su un HTTP GET. I proxy HTTP presumono che dal momento che HTTP GET non modifica lo stato, non importa se un utente invoca HTTP GET una volta o 1000 volte. Usando queste informazioni si presume che sia sicuro restituire una versione cache del primo HTTP GET. Se si infrangono le specifiche HTTP si rischia di violare client HTTP e proxy in natura. Non farlo :)

Ciò attraversa il concetto di REST e il modo in cui la rete era intesa per essere utilizzata. V'è un eccellente podcast di radio software ingegneristico che fornisce un approfondito discorso circa l'uso di GET e POST.

Get viene utilizzato per estrarre i dati dal server, dove non dovrebbe essere necessaria un'azione di aggiornamento. L'idea è che dovresti essere in grado di utilizzare più volte la stessa richiesta GET e ottenere le stesse informazioni restituite. L'URL contiene le informazioni di acquisizione nella stringa di query, perché doveva essere facilmente inviato ad altri sistemi e persone come un indirizzo su dove trovare qualcosa.

Si suppone che Post venga utilizzato (almeno dall'architettura REST su cui si basa il web) per inviare informazioni al server / dire al server di eseguire un'azione. Esempi come: Aggiorna questi dati, Crea questo record.

1.3 Elenco di controllo rapido per la scelta di HTTP GEToPOST

Usa OTTIENI se:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Usa POST se:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Fonte .

non vedo un problema usando get, però lo uso per cose semplici in cui ha senso tenere le cose sulla stringa di query.

Usarlo per aggiornare lo stato - come GET delete.php?id=5per eliminare una pagina - è molto rischioso. La gente lo ha scoperto quando l'acceleratore web di Google ha iniziato a precaricare gli URL sulle pagine: ha colpito tutti i link "elimina" e cancellato i dati delle persone. La stessa cosa può succedere con i ragni dei motori di ricerca.

POST può spostare dati di grandi dimensioni mentre GET no.

Ma generalmente non si tratta di una mancanza di GET, piuttosto di una convenzione se si desidera che il proprio sito Web / webapp si comporti bene.

Dai un'occhiata a http://www.w3.org/2001/tag/doc/whenToUseGet.html

Da RFC 2616 :

9.3 OTTENERE
Il metodo OTTENERE significa recuperare qualsiasi informazione (sotto forma di entità) identificata dall'URI di richiesta. Se l'URI della richiesta fa riferimento a un processo di produzione di dati, sono i dati prodotti che devono essere restituiti come entità nella risposta e non il testo di origine del processo, a meno che tale testo non sia l'output del processo.

9.5 POST
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. POST è progettato per consentire a un metodo uniforme di coprire le seguenti funzioni:

• Annotazione di risorse esistenti;
• Pubblicare un messaggio su una bacheca, un newsgroup, una mailing list o un gruppo simile di articoli;
• Fornire un blocco di dati, come il risultato dell'invio di un modulo, a un processo di gestione dei dati;
• Estensione di un database tramite un'operazione di accodamento.

La funzione effettiva eseguita dal metodo POST è determinata dal server e di solito dipende dall'URI di richiesta. L'entità pubblicata è subordinata a tale URI nello stesso modo in cui un file è subordinato a una directory che lo contiene, un articolo di notizie è subordinato a un newsgroup in cui è pubblicato o un record è subordinato a un database.

L'azione eseguita dal metodo POST potrebbe non comportare una risorsa che può essere identificata da un URI. In questo caso, 200 (OK) o 204 (Nessun contenuto) è lo stato di risposta appropriato, a seconda che la risposta includa o meno un'entità che descrive il risultato.

Uso POST quando non voglio che le persone vedano QueryString o quando QueryString diventa grande. Inoltre, POST è necessario per i caricamenti di file.

Tuttavia, non vedo alcun problema nell'utilizzo di GET, lo uso per cose semplici in cui ha senso tenere le cose su QueryString.

L'uso di GET consentirà anche il collegamento a una determinata pagina in cui il POST non funzionerebbe.

L'intento originale era che GET fosse usato per recuperare i dati e che il POST doveva essere qualsiasi cosa. La regola empirica che utilizzo è che se invio qualcosa al server, utilizzo POST. Se sto solo chiamando un URL per recuperare i dati, utilizzo GET.

Leggi l' articolo su HTTP nella Wikipedia . Spiegherà cos'è il protocollo e cosa fa:

OTTENERE

Richiede una rappresentazione della risorsa specificata. Si noti che GET non deve essere utilizzato per operazioni che causano effetti collaterali, come l'utilizzo per eseguire azioni nelle applicazioni Web. Uno dei motivi è che GET può essere utilizzato in modo arbitrario da robot o crawler, il che non dovrebbe considerare gli effetti collaterali che una richiesta dovrebbe causare.

e

POST Invia i dati da elaborare (ad es. Da un modulo HTML) alla risorsa identificata. I dati sono inclusi nel corpo della richiesta. Ciò può comportare la creazione di una nuova risorsa o l'aggiornamento di risorse esistenti o entrambi.

Il W3C ha un documento chiamato URI, indirizzabilità e l'uso di HTTP GET e POST che spiega quando usare cosa. citando

1.3 Elenco di controllo rapido per la scelta di HTTP GET o POST

• Usa OTTIENI se:
  • L'interazione è più simile a una domanda (ovvero, è un'operazione sicura come una query, un'operazione di lettura o una ricerca).

e

• Usa POST se:
  • L'interazione è più simile a un ordine, oppure
  • L'interazione modifica lo stato della risorsa in modo che l'utente possa percepire (ad esempio un abbonamento a un servizio) oppure o L'utente deve essere ritenuto responsabile dei risultati dell'interazione.

Tuttavia, prima della decisione finale di utilizzare HTTP GET o POST, considerare anche considerazioni su dati sensibili e considerazioni pratiche.

Un esempio pratico potrebbe essere ogni volta che invii un modulo HTML. È possibile specificare post o ottenere per l'azione del modulo. PHP popolerà di conseguenza $ _GET e $ _POST.

In PHP, il POSTlimite di dati è di solito impostato dal tuo php.ini. GETcredo sia limitato dalle impostazioni del server / browser, di solito intorno ai 255byte.

Da w3schools.com :

Che cos'è HTTP?

Hypertext Transfer Protocol (HTTP) è progettato per consentire le comunicazioni tra client e server.

HTTP funziona come protocollo di richiesta-risposta tra un client e un server.

Un browser Web può essere il client e un'applicazione su un computer che ospita un sito Web può essere il server.

Esempio: un client (browser) invia una richiesta HTTP al server; quindi il server restituisce una risposta al client. La risposta contiene informazioni sullo stato della richiesta e può anche contenere il contenuto richiesto.

Due metodi di richiesta HTTP: GET e POST

Due metodi comunemente usati per una richiesta-risposta tra un client e un server sono: GET e POST.

OTTIENI: richiede dati da una risorsa specificata POST: invia i dati da elaborare a una risorsa specifica

Qui distinguiamo le principali differenze:

Versione semplice di POST GET PETE DELETE

• usa GET - quando vuoi ottenere qualsiasi risorsa come Elenco di dati basato su qualsiasi ID o nome
• usa POST - quando vuoi inviare qualsiasi dato al server. tieni presente che POST è un'operazione pesante perché per l'aggiornamento dovremmo usare PUT invece di POST internamente POST creerà una nuova risorsa
• usa PUT - quando lo fai

Bene, una cosa importante è che tutto ciò che invii GETverrà esposto tramite l'URL. In secondo luogo, come afferma Ceejayoz, esiste un limite per i caratteri per un URL.

Un'altra differenza è che il POST richiede generalmente due operazioni HTTP, mentre GET ne richiede solo una.

Modifica: dovrei chiarire - per schemi di programmazione comuni. Generalmente rispondere a un POST con una semplice pagina Web HTML è una progettazione discutibile per una serie di motivi, uno dei quali è il fastidioso "è necessario inviare nuovamente questo modulo, si desidera farlo?" premendo il pulsante indietro.

Come hanno risposto altri, esiste un limite alla dimensione dell'URL con get e i file possono essere inviati solo con posta.

Vorrei aggiungere che si possono aggiungere cose a un database con get ed eseguire azioni con un post. Quando uno script riceve un post o un get, può fare tutto ciò che l'autore vuole che faccia. Credo che la mancanza di comprensione derivi dalle parole scelte dal libro o da come lo leggi.

Un autore di script dovrebbe utilizzare i post per modificare il database e utilizzare get solo per il recupero di informazioni.

I linguaggi di scripting hanno fornito molti mezzi per accedere alla richiesta. Ad esempio, PHP consente di $_REQUESTrecuperare un post o un get. Uno dovrebbe evitare questo a favore del più specifico $_GETo $_POST.

Nella programmazione web, c'è molto più spazio per l'interpretazione. C'è cosa si dovrebbe e cosa si può fare, ma quale è meglio è spesso oggetto di dibattito. Fortunatamente, in questo caso, non c'è ambiguità. Si consiglia di utilizzare i messaggi per modificare i dati, e si dovrebbe utilizzare Get per recuperare le informazioni.

Gorgapor, mod_rewriteancora spesso utilizza GET. Permette solo di tradurre un URL più amichevole in un URL con una GETstringa di query.

I dati HTTP Post non hanno un limite specificato sulla quantità di dati, laddove browser diversi hanno limiti diversi per GET. RFC 2068 afferma:

I server devono essere cauti a seconda della lunghezza dell'URI superiore a 255 byte, poiché alcune implementazioni client o proxy precedenti potrebbero non supportare correttamente tali lunghezze

In particolare, dovresti avere i costrutti HTTP giusti per quello per cui sono usati. I HTTP GET non dovrebbero avere effetti collaterali e possono essere tranquillamente aggiornati e archiviati dai proxy HTTP, ecc.

I POST HTTP vengono utilizzati quando si desidera inviare dati a una risorsa url.

Un esempio tipico per l'utilizzo di HTTP GET è su una ricerca, ovvero Cerca? Query = my + query Un esempio tipico per l'utilizzo di un HTTP POST è l'invio di feedback a un modulo online.