GET vs POST nel servizio Web REST

Question

Sono in procinto di sviluppare un servizio REST che consente a un utente di reclamare la propria scheda in base a un paio di informazioni visualizzate sulla fattura (numero di fattura e codice di fatturazione).

Ho letto innumerevoli articoli e domande Stack Overflow su quando utilizzare GET e quando utilizzare POST. Nel complesso, il consenso comune è che GET dovrebbe essere utilizzato per le operazioni idempotent e il POST dovrebbe essere utilizzato per operazioni che creano qualcosa sul lato server. Tuttavia, questo articolo:

http://blog.teamtreehouse.com/the-definitive-guide-to-get-vs-post

mi ha causato a mettere in discussione utilizzando GET per questo scenario particolare, semplicemente a causa del fatto che sto usando questi 2 pezzi di informazioni come un meccanismo per convalidare l'identità del utente. Non sto aggiornando nulla sul server utilizzando questa particolare chiamata di metodo, ma non voglio necessariamente esporre le informazioni nell'URL.

Questo è un servizio Web interno e solo il front-end che chiama il servizio è esposto pubblicamente, quindi non devo preoccuparmi dell'URL visualizzato nella cronologia del browser di un utente. La mia unica preoccupazione sarebbe l'improbabile eventualità che qualcuno ottenga l'accesso al registro del server, nel qual caso avrò maggiori problemi.

Sono incline al POST per motivi di sicurezza; tuttavia, GET sembra il metodo corretto a causa del fatto che la richiesta è idempotente. Qual è il metodo consigliato in questo caso?

Answer 1

Indipendentemente da POST vs GET, mi sento di raccomandare di non basare la vostra sicurezza come qualcosa di semplice come un codice di avviamento postale e un numero di fattura. Scommetterei sul fatto che i numeri delle fatture sono sequenziali (o chiusi), e non ci sono molti codici postali in giro - voilà, ho avuto pieno accesso alle tue inserzioni.

Se si utilizza un altro metodo di autenticazione (in genere nell'intestazione HTTP), allora si sta bene - non importa se si dispone di un numero di fattura se l'URL, quindi potrebbe anche utilizzare GET.

Se non lo sei, suppongo che POST non sia così grave come GET in termini di esposizione di contenuti riservati.

Answer 2

Non c'è alcuna sicurezza aggiunta in un POST o GET. Certo, la richiesta non è nell'URL, ma è REST di cui stiamo parlando qui, e l'URL non sarebbe comunque visto da un umano.

Answer 3

La domanda inizia con alcune cattive presunzioni. Innanzitutto, GET non è solo per qualsiasi operazione precedente idempotente, è per le risorse GET ting dal server; succede solo che così facendo dovrebbe essere senza effetti collaterali. In secondo luogo, l'URL non è l'unico modo per una richiesta GET di inviare dati al server, è possibile utilizzare un carico utile con una richiesta GET (almeno per quanto riguarda HTTP, alcune implementazioni sono cattive e non supportano questo o fallo difficile). In terzo luogo, come sottolineato, hai scelto alcuni campi di dati terribili per garantire il tuo accesso. Infine, si sta utilizzando un protocollo di testo normale in qualsiasi modo, quindi ciò che nessuno dei due metodi offre e una maggiore sicurezza.

È necessario utilizzare il verbo che descrive meglio ciò che si sta facendo, si stanno ottenendo alcune informazioni dal server, quindi utilizzare GET. Utilizzare una sicurezza adeguata, come la crittografia HTTPS di base. Se si desidera evitare che questi campi "ostruiscano" l'URL, è possibile inviare dati nel carico utile della richiesta, ad esempio:

GET /listings HTTP/1.1 
Content-Type = application/json 

{ "zip"  : "IN0N0USZ1PC0D35", 
    "invoice" : "54859081145" }