Perché si sta utilizzando un GET HTTP per aggiornare lo stato sul server in una chiamata RESTful errata?

Question

OK, so già tutte le ragioni su carta perché dovrei non utilizzare un HTTP GET quando si effettua una chiamata RESTful per aggiornare lo stato di qualcosa sul server. In questo modo restituire dati possibilmente diversi ogni volta. E so che questo è sbagliato per il seguente 'sulla carta' ragioni:

• HTTP GET le chiamate devono essere idempotente
• N> 0 chiamate dovrebbe sempre avere gli stessi dati storici
• viola spec HTTP
• La chiamata HTTP GET è in genere di sola lettura

E sono sicuro che ci sono più motivi. Ma ho bisogno di un esempio semplice e concreto di giustificazione oltre a "Beh, questo viola le specifiche HTTP!". ... o almeno spero in uno. Ho anche già letto il seguito della quale sono più lungo le linee della lista di cui sopra: Does it violate the RESTful when I write stuff to the server on a GET call? & HTTP POST with URL query parameters -- good idea or not?

Per esempio, qualcuno può giustificare la sopra e perché è sbagliato/cattiva pratica/errato di utilizzare un HTTP GET voce con la seguente chiamata RESTful

"MyRESTService/GetCurrentRecords?UpdateRecordID=5&AddToTotalAmount=10" 

So che è sbagliato, ma si spera che possa fornire un esempio per rispondere alla mia domanda originale. Quindi quanto sopra aggiornerebbe recordID = 5 con AddToTotalAmount = 10 e quindi restituirà i record aggiornati. So che un POST dovrebbe essere usato, ma diciamo che ho usato un GET.

Come esattamente e rispondere alla mia domanda fa o può questo causare un vero e proprio problema? Oltre a tutte le violazioni dalla lista puntata precedente, come utilizzare un GET HTTP per fare quanto sopra causa qualche problema reale? Troppe volte arrivo in uno scenario in cui posso giustificare le cose con "Perché il dottore ha detto così", ma ho bisogno di una giustificazione e di una comprensione migliore su questo.

Grazie!

Answer 1

Il caso pratico in cui si verificherà un problema è che il GET HTTP viene spesso ritentato in caso di errore dall'implementazione HTTP. Quindi nella vita reale puoi ottenere situazioni in cui lo stesso GET viene ricevuto più volte dal server. Se il tuo aggiornamento è idempotente (che è il tuo), non ci saranno problemi, ma se non è idempotente (ad esempio aggiungendo un valore ad un importo, ad esempio), potresti ottenere più aggiornamenti (indesiderati).

HTTP POST non viene mai ripetuto, quindi non avresti mai questo problema.

Answer 2

Penso che leggere questa risorsa: http://www.servicedesignpatterns.com/WebServiceAPIStyles potrebbe essere utile per fare la differenza tra API dei messaggi e API delle risorse?

Answer 3

Se qualche forma di motore di ricerca spider il tuo sito potrebbe modificare i tuoi dati involontariamente.

Questo è accaduto in passato con Google Desktop Search che ha causato la perdita di dati da parte degli utenti perché le persone avevano implementato le operazioni di eliminazione come GET.

Answer 4

Questa è una ragione importante per cui GET deve essere idempotente e non deve essere utilizzato per l'aggiornamento dello stato sul server in merito agli Attacchi di falsi. Dal libro: Professional ASP.NET MVC 3

idempotent GET
Grande parola, di sicuro - ma è un concetto semplice. Se l'operazione è idempotente, può essere eseguita più volte senza cambiando il risultato. In generale, una buona regola empirica è che puoi evitare un'intera classe di attacchi CSRF modificando solo le cose nel tuo DB o sul tuo sito utilizzando il POST. Ciò significa Registrazione, Logout, Login e così via. Per lo meno, ciò limita in qualche modo gli attacchi delegati confusi .