Metodi HTTP: che dire solo dell'uso del POST per le chiamate Ajax?

3

Puoi trovare la teorizzazione di interi articoli quando dovresti usare cosa METHOD in quale caso limite.

Si tratta principalmente di questo; ogni azione deve essere semplificata in soli quattro gusti (GET, POST, PUT, DELETE) - e questo spesso non è sufficiente per essere espressivi.

Soprattutto se si guarda al design guidato da domini, questo non è adatto. Direi che ogni sviluppatore che cerca di calzare tutto il suo codice in questi metodi (nel loro codice Java) avrà dei brutti momenti durante le revisioni del codice. Devi chiaramente avere la documentazione per essere veramente sicuro di cosa sta succedendo.

/employees/active/john-doe (DELETE)

ELIMINA significa CANCELLARE la risorsa, o ELIMINARE (rimuoverla) dalla lista 'attiva'?

/employees/active/john-doe/remove-from-active

sarebbe molto più espressivo. Chiunque utilizzi questo metodo sarà sicuro di non eliminare accidentalmente questo dipendente. POST, GET, a chi importa - purché siamo autorizzati.

Probabilmente alcune persone teorizzeranno che il primo URL non è comunque espressivo, ma cosa aggiungerebbe realmente il metodo DELETE ? Se l'URL su se stesso è espressivo - non è il DELETE metodo informazioni duplicate (non DRY )?

C'è qualcosa di sbagliato nell'essere pragmatico e usare sempre il POST?

Da un po 'di tempo uso solo i metodi POST per tutte le mie chiamate Ajax. Tranne alcuni problemi di memorizzazione nella cache, non vedo alcun problema.

Anche se preferirei abbandonare il Metodo, penso ci sia in realtà una più chiara distinzione tra GET e POST , perché GET esprime nessun effetto collaterale .

Mi manca qualcosa o siamo (come comunità internet) che abbracciamo il design del legacy solo perché è già lì e siamo bloccati con esso? Ci sono buoni argomenti che Http Method sia un 'buon design', oltre al fatto che dovremmo attenerci alle convenzioni già presenti?

    
posta Dirk Boer 26.07.2018 - 13:50
fonte

2 risposte

3

Gli argomenti per utilizzare i metodi GET, POST, PUT e DELETE per le chiamate HTTP di solito ruotano intorno ai servizi web RESTful. REST ( Representational State Transfer ) è solo un tentativo di sfruttare il protocollo HTTP esistente per qualcosa di più che "SUCCESSO!" o "FAIL!" tipo di messaggi.

Se non stai aderendo alle linee guida di REST, allora non c'è nulla di sbagliato nella scelta delle richieste GET o POST.

(Nella voce burbero-vecchio) nel giorno era "best practice" per tutte le chiamate AJAX essere richieste POST in modo che qualcuno non potesse lanciare un attacco sul tuo sito inserendo un piccolo tag JavaScript su un hacker sito web:

<script type="text/javascript" src="https://www.yourcompany.com/ajax?foo=bar"></script>

E poi ingannare gli utenti (si spera abbiano effettuato l'accesso) per visitare il sito.

Il browser esegue ancora la richiesta HTTP GET. Invia ancora i cookie al server comunicando alla tua app che sono connessi. Sicuro che il browser non può eseguire il risultato, ma la richiesta è stata elaborata ed elaborata.

Se il tuo endpoint AJAX risponde alle richieste POST o PUT, è molto più difficile eseguire questo tipo di attacco (end-fruff old-man voice).

    
risposta data 26.07.2018 - 14:04
fonte
1

Is there anything wrong with being pragmatic and always use POST?

No, è grandioso.

are we (as internet community) embracing legacy design just because it is already there and we are stuck with it?

Jeeze I deve diventare vecchio se REST è legacy ora.

Le persone discutono di RESTfullness perché è un insieme di regole su cui discutere.

Le persone come riposano perché è facile rispetto a SOAP e simili. esp. per gli sviluppatori web che stanno già utilizzando HTTP dappertutto.

Ci sono alcuni evidenti difetti tecnici / domande con il tentativo di inserire le cose nei metodi HTTP

  • Lunghezza della restrizione URL su GET
  • Può avere un corpo
  • Un server API dovrebbe avere le stesse regole di caching di un server web?
  • Invio di elenchi di elementi in un URL
  • Che cosa significa il codice 202 veramente ?
  • Se il server web registra l'URL della richiesta

ecc.

Alla fine della giornata la "specifica" REST non è abbastanza rigorosa da dirti quale metodo usare, anche se non vuoi seguirlo

    
risposta data 26.07.2018 - 14:06
fonte

Leggi altre domande sui tag