Perché non utilizzare PUT per le query REST che richiedono un payload?

Question

REST consiglia di eseguire le query (non creazione di risorse) tramite il metodo GET. In alcuni casi, i dati della query sono troppo grandi o strutturati in modo da rendere difficile l'inserimento di un URL e, per risolvere il problema, un'API RESTful viene modificata per supportare le query con i corpi.

Sembra che la convenzione per le query RESTful che richiedono corpi sia quella di utilizzare POST. Ecco alcuni esempi:

• Dropbox API
• ElasticSearch
• Restful Web Services Cookbook

query di O'Reilley non modificano lo stato interno del sistema, ma il POST non supporta le operazioni idempotenti . Tuttavia, PUT è idempotente. Perché le API RESTful non usano PUT con un corpo invece di POST per le query che richiedono un corpo?

NOTA:A popular question chiede quale (PUT vs POST) è preferito per la creazione di una risorsa. Questa domanda chiede perché PUT non viene utilizzato per le query che richiedono corpi.

Answer 1

No. PUT potrebbe essere idempotente, ma ha anche un significato specifico. Il corpo della richiesta in PUT deve essere utilizzato per sostituire la risorsa nell'URI.

Con POST non sono state fatte tali ipotesi. E nota che l'utilizzo di una richiesta POST significa che la richiesta potrebbe non essere idempotente, in casi specifici potrebbe ancora essere.

Tuttavia, è possibile farlo con PUT, ma richiede di passare attraverso un telaio aggiuntivo. Fondamentalmente, è possibile creare una "risorsa query" con PUT e quindi utilizzare immediatamente GET per recuperare i risultati di questa risorsa di query. Forse questo era ciò che cercavi, ma questo è il più RESTful, perché i risultati delle query risultanti possono ancora essere collegati. (qualcosa che è completamente mancante se si utilizzano le richieste POST).

Answer 2

Si consiglia di leggere lo standard: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

La definizione di post:

Il metodo POST viene utilizzato per richiedere che il server di origine accettare la un'entità racchiusa nella richiesta come una nuova subordinato la risorsa identificata dall'URI di richiesta nella riga di richiesta.

L'azione eseguita dal metodo POST potrebbe non dare come risultato 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 o meno la risposta includa un'entità che descrive il risultato.

La definizione di PUT

Le richieste metodo put che l'entità racchiuso essere conservato sotto il fornito Request-URI. Se l'URI di richiesta fa riferimento a una risorsa già esistente, l'entità inclusa DOVREBBE essere considerata come una versione modificata di di quella che risiede sul server di origine. Se l'URI di richiesta non punta a una risorsa esistente e quell'URI è in grado di definire come una nuova risorsa dall'agente utente richiedente, il server di origine può creare la risorsa con quell'URI.

Se la risorsa non può essere creata o modificata con l'URI di richiesta, è necessario fornire una risposta di errore appropriata che rifletta la natura del problema.

Un'altra cosa che PUT non è memorizzabile nella cache mentre POST è.

Le risposte a questo metodo non sono memorizzabili nella cache, a meno che la risposta non contenga i campi di intestazione Cache-Control o Expires appropriati.

ad es. http://www.ebaytechblog.com/2012/08/20/caching-http-post-requests-and-responses/