POST HTTP con parametri di query URL: buona idea o no? [chiuso]

Sto progettando un'API per andare su HTTP e mi chiedo se usare il comando HTTP POST, ma con solo i parametri di query URL e nessun corpo di richiesta, sia un buon modo di procedere.

considerazioni:

• "Good Web design" richiede che le azioni non idempotenti vengano inviate tramite POST. Questa è un'azione non idempotente.
• È più semplice sviluppare ed eseguire il debug di questa app quando i parametri della richiesta sono presenti nell'URL.
• L'API non è destinata ad un uso diffuso.
• Sembra che fare una richiesta POST senza body richiederà un po 'più di lavoro, ad esempio Content-Length: 0un'intestazione deve essere aggiunta esplicitamente.
• Mi sembra anche che un POST senza body sia un po 'contrario alle aspettative della maggior parte dei framework HTTP e degli sviluppatori.

Ci sono più insidie ​​o vantaggi nell'invio di parametri su una richiesta POST tramite la query URL anziché il corpo della richiesta?

Modifica: il motivo per cui questo è in considerazione è che le operazioni non sono idempotenti e hanno effetti collaterali diversi dal recupero. Vedi le specifiche HTTP :

In particolare, è stata stabilita la convenzione che i metodi GET e HEAD NON DOVREBBERO avere il significato di intraprendere un'azione diversa dal recupero. Questi metodi dovrebbero essere considerati "sicuri". Ciò consente agli interpreti utenti di rappresentare altri metodi, come POST, PUT e DELETE, in modo speciale, in modo che l'utente venga a conoscenza del fatto che viene richiesta un'azione potenzialmente non sicura.

...

I metodi possono anche avere la proprietà di "idempotenza" in quanto (a parte errori o problemi di scadenza), gli effetti collaterali di richieste identiche N> 0 sono gli stessi di una singola richiesta. I metodi GET, HEAD, PUT e DELETE condividono questa proprietà. Inoltre, i metodi OPTIONS e TRACE NON DOVREBBERO avere effetti collaterali, e quindi sono intrinsecamente idempotenti.

Se la tua azione non è idempotente, DEVI usare POST. In caso contrario, stai solo chiedendo problemi lungo la linea. GET, PUTE DELETEmetodi sono necessari per essere idempotente. Immagina cosa accadrebbe nella tua applicazione se il client stesse pre-recuperando ogni possibile GETrichiesta per il tuo servizio - se ciò causasse effetti collaterali visibili al client, allora qualcosa non va.

Concordo sul fatto che inviare a POSTcon una stringa di query ma senza un corpo sembra strano, ma penso che possa essere appropriato in alcune situazioni.

Pensa alla parte della query di un URL come un comando alla risorsa per limitare l'ambito della richiesta corrente. In genere, le stringhe di query vengono utilizzate per ordinare o filtrare una GETrichiesta (come ?page=1&sort=title), ma suppongo che abbia senso POSTlimitare anche l'ambito (forse come ?action=delete&id=5).

Tutti hanno ragione: attenersi al POST per richieste non idempotenti.

Che ne dici di usare sia una stringa di query URI sia il contenuto della richiesta? Bene, è un HTTP valido (vedi nota 1), quindi perché no ?!

È anche perfettamente logico: gli URL, inclusa la parte della stringa di query, servono per individuare le risorse. Considerando che i verbi del metodo HTTP (POST - e il suo contenuto di richiesta opzionale) servono per specificare le azioni o cosa fare con le risorse. Quelle dovrebbero essere preoccupazioni ortogonali. (Ma non sono meravigliosamente preoccupazioni ortogonali per il caso speciale di ContentType = application / x-www-form-urlencoded, vedere la nota 2 di seguito.)

Nota 1: la specifica HTTP (1.1) non afferma che i parametri e il contenuto della query si escludono a vicenda per un server HTTP che accetta richieste POST o PUT. Quindi qualsiasi server è libero di accettare entrambi. Vale a dire se si scrive sul server non c'è nulla che ti impedisca di scegliere di accettare entrambi (tranne forse un framework non flessibile). In generale, il server può interpretare le stringhe di query in base alle regole che desidera. Può persino interpretarli con una logica condizionale che fa riferimento anche ad altre intestazioni come Content-Type, che porta alla Nota 2:

Nota 2: se un browser Web è il modo principale in cui le persone accedono alla tua applicazione Web e application / x-www-form-urlencoded è il Tipo di contenuto che pubblicano, allora dovresti seguire le regole per quel Tipo di contenuto. E le regole per application / x-www-form-urlencoded sono molto più specifiche (e francamente, inusuali): in questo caso è necessario interpretare l'URI come un insieme di parametri e non come una posizione delle risorse. [Questo è lo stesso punto di utilità sollevato da Powerlord; che potrebbe essere difficile utilizzare i moduli Web per pubblicare il contenuto sul server. Ho solo spiegato un po 'diversamente.]

Nota 3: a cosa servono originariamente le stringhe di query? RFC 3986 definisce le stringhe di query HTTP come una parte URI che funziona come un modo non gerarchico di localizzazione di una risorsa.

Nel caso in cui i lettori che fanno questa domanda desiderano porre ciò che è buona architettura RESTful: il modello di architettura RESTful non richiede schemi URI per funzionare in un modo specifico. L'architettura RESTful si occupa di altre proprietà del sistema, come la cache delle risorse, la progettazione delle risorse stesse (comportamento, capacità e rappresentazioni) e se l'idempotenza è soddisfatta. O in altre parole, ottenere un design altamente compatibile con il protocollo HTTP e il suo set di verbi del metodo HTTP. :-) (In altre parole, l'architettura RESTful non è molto prescrittiva su come si trovano le risorse .)

Nota finale: a volte i parametri della query vengono utilizzati per altre cose, che non localizzano risorse né codificano il contenuto. Hai mai visto un parametro di query come 'PUT = true' o 'POST = true'? Queste sono soluzioni alternative per i browser che non ti consentono di utilizzare i metodi PUT e POST. Mentre tali parametri sono visti come parte della stringa di query dell'URL (sul filo), sostengo che non fanno parte della query dell'URL nello spirito .

Vuoi ragioni? Eccone uno:

Non è possibile utilizzare un modulo Web per inviare una richiesta a una pagina che utilizza un mix di GET e POST. Se si imposta il metodo del modulo su GET, tutti i parametri si trovano nella stringa della query. Se si imposta il metodo del modulo su POST, tutti i parametri si trovano nel corpo della richiesta.

Fonte: HTML 4.01 standard, sezione 17.13 Invio modulo

Da un punto di vista programmatico, per il cliente è impacchettare i parametri e aggiungerli all'URL e condurre un POST contro un GET. Sul lato server, sta valutando i parametri in entrata dalla stringa di query anziché dai byte postati. Fondamentalmente, è un lavaggio.

Dove potrebbero esserci vantaggi / svantaggi potrebbe essere il modo in cui piattaforme client specifiche funzionano con le routine POST e GET nel loro stack di rete, nonché in che modo il server Web gestisce tali richieste. A seconda dell'implementazione, un approccio può essere più efficiente dell'altro. Sapere che guiderebbe la tua decisione qui.

Tuttavia, dal punto di vista di un programmatore, preferisco consentire un POST con tutti i parametri nel corpo o un GET con tutti i parametri sull'URL e ignorare esplicitamente i parametri dell'URL con qualsiasi richiesta POST. Evita la confusione.

Penso che potrebbe essere ancora abbastanza RESTful avere argomenti di query che identificano la risorsa sull'URL mantenendo il payload del contenuto limitato al corpo POST. Ciò sembrerebbe separare le considerazioni di "Che cosa sto inviando?" contro "A chi lo sto inviando?".

Il campo REST ha alcuni principi guida che possiamo usare per standardizzare il modo in cui usiamo i verbi HTTP. Questo è utile quando si creano API RESTful mentre si sta facendo.

In breve: GET dovrebbe essere di sola lettura, cioè non avere alcun effetto sullo stato del server. POST viene utilizzato per creare una risorsa sul server. PUT viene utilizzato per aggiornare o creare una risorsa. DELETE viene utilizzato per eliminare una risorsa.

In altre parole, se l'azione dell'API modifica lo stato del server, REST ci consiglia di utilizzare POST / PUT / DELETE, ma non GET.

I programmi utente di solito comprendono che eseguire più POST è un male e lo avvertiranno, perché l'intenzione di POST è di modificare lo stato del server (ad es. Pagare la merce alla cassa), e probabilmente non vorrai farlo due volte!

Confronta con un GET che puoi fare spesso come preferisci (idempotente).

Sono d'accordo - probabilmente è più sicuro utilizzare una richiesta GET se stai semplicemente passando i dati nell'URL e non nel corpo. Vedi questa domanda simile per alcune viste aggiuntive sull'intero concetto POST + GET.