Ho letto molte cose su questo argomento, ma non sono in grado di ottenere la conclusione su questo argomento.
Ma non ho mai usato i metodi PUT o DELETE HTTP Request. La mia tendenza è quella di utilizzare GET quando le statistiche del sistema (la mia applicazione o il sito Web) potrebbero non essere influenzate (come l'elenco dei prodotti) e di utilizzare POST quando sono interessate (ordine effettuato). Non è sufficiente o mi manca qualcosa?
Risposte:
DELETE serve per eliminare la risorsa richiesta:
Il metodo DELETE richiede che il server di origine elimini la risorsa identificata dall'URI della richiesta. Questo metodo PU essere sovrascritto dall'intervento umano (o da altri mezzi) sul server di origine. Non è possibile garantire al client che l'operazione sia stata eseguita, anche se il codice di stato restituito dal server di origine indica che l'azione è stata completata con successo ...
PUT serve per inserire o aggiornare una risorsa sul server:
Il metodo PUT richiede che l'entità racchiusa venga archiviata sotto l'URI di richiesta fornito. Se l'URI della richiesta fa riferimento a una risorsa già esistente, l'entità racchiusa DOVREBBE essere considerata come una versione modificata di quella che risiede sul server di origine. Se l'URI della richiesta non punta a una risorsa esistente e l'URI può essere definito come nuova risorsa dall'agente utente richiedente, il server di origine può creare la risorsa con quell'URI ...
Per le specifiche complete, visitare:
Poiché i browser attuali sfortunatamente non supportano altri verbi oltre a POST e GET nei moduli HTML , di solito non è possibile utilizzare HTTP al massimo con essi (è comunque possibile dirottare la loro presentazione tramite JavaScript). L'assenza di supporto per questi metodi nei moduli HTML ha portato a URI contenenti verbi, come ad esempio
POST http://example.com/order/1/delete
o anche peggio
POST http://example.com/deleteOrder/id/1
tunneling efficace della semantica CRUD su HTTP. Ma i verbi non sono mai stati pensati per far parte dell'URI. Invece HTTP fornisce già il meccanismo e la semantica per CRUD una risorsa (ad esempio un ordine) tramite i metodi HTTP. HTTP è un protocollo e non solo un servizio di tunneling dei dati.
Quindi, per eliminare una risorsa sul server web, devi chiamare
DELETE http://example.com/order/1
e per aggiornarlo chiameresti
PUT http://example.com/order/1
e fornire la rappresentazione delle risorse aggiornata nell'organismo PUT affinché il server web si applichi.
Quindi, se stai creando una sorta di client per un'API REST , è probabile che invii richieste PUT e DELETE. Potrebbe essere un client costruito all'interno di un browser, ad esempio l'invio di richieste tramite JavaScript o potrebbe essere uno strumento in esecuzione su un server, ecc.
Per ulteriori dettagli visitare:
L'utilizzo del verbo di richiesta HTTP come GET, POST, DELETE, PUT ecc ... consente di creare applicazioni Web RESTful. Leggi qui: http://en.wikipedia.org/wiki/Representational_state_transfer
Il modo più semplice per vedere i benefici da questo è guardare questo esempio. Ogni framework MVC ha un Router/Dispatcherche mappa gli URL su actionControllers. Quindi URL come questo: /blog/article/1invocerebbe blogController::articleAction($id);
ora questo router è a conoscenza solo dell'URL o/blog/article/1/
Ma se quel router fosse a conoscenza dell'intero oggetto Richiesta HTTP invece del solo URL, potrebbe avere accesso al verbo Richiesta HTTP (GET, POST, PUT, DELETE ...) e molte altre cose utili sulla richiesta HTTP corrente.
Ciò consentirebbe di configurare l'applicazione in modo che possa accettare lo stesso URL e mapparlo a diversi actionController a seconda del verbo di richiesta HTTP.
Per esempio:
se vuoi recuperare l'articolo 1 puoi farlo:
GET /blog/article/1 HTTP/1.1
ma se vuoi eliminare l'articolo 1 lo farai:
DELETE /blog/article/1 HTTP/1.1
Si noti che entrambe le richieste HTTP hanno lo stesso URI, / blog / articolo / 1, l'unica differenza è il verbo di richiesta HTTP. E in base a quel verbo il tuo router può chiamare differenti actionController. Ciò ti consente di creare URL accurati.
Leggi questi due articoli, potrebbero aiutarti:
Symfony 2 - Fondamenti di HTTP
Questi articoli riguardano il framework Symfony 2, ma possono aiutarti a capire come funzionano le richieste e le risposte HTTP.
Spero che sia di aiuto!
Createe 1 per Delete. Se lo fai, la tua prossima ricerca sarà " Come avere più azioni Post in un singolo controller ": P. Non che questo sia orribile, ma perdi la possibilità di avere una risorsa unica da implementare tramite l'azione verbale invece di dover fornire esplicitamente il nome dell'azione nell'URI.
Anche se corro il rischio di non essere popolare, dico che non sono utili al giorno d'oggi .
Penso che fossero ben intenzionati e utili in passato quando per esempio DELETE ha detto al server di eliminare la risorsa trovata all'URL fornito e PUT (con il suo fratello PATCH) ha detto al server di eseguire l'aggiornamento in modo idempotente.
Le cose si sono evolute e gli URL sono diventati virtuali (vedi riscrittura URL per esempio) facendo perdere alle risorse il loro significato iniziale di cartella / subforder / file reale e così, i verbi di azione CRUD coperti dai metodi del protocollo HTTP (GET, POST, PUT / PATCH, DELETE) hanno perso traccia .
Facciamo un esempio:
Sul lato sinistro non è scritto il metodo HTTP, essenzialmente non importa (sono sufficienti POST e GET) e sul lato destro vengono utilizzati metodi HTTP appropriati.
Il lato destro sembra elegante, pulito e professionale. Immagina ora di dover mantenere un codice che utilizza l'elegante API e di dover cercare dove viene eseguita la chiamata di cancellazione. Potrai cercare "api / entità" e tra i risultati si dovrà vedere quale sta facendo DELETE. O peggio ancora, hai un programmatore junior che per errore ha cambiato PUT con DELETE e poiché URL è successo la stessa merda.
A mio parere, inserire il verbo di azione nell'URL presenta dei vantaggi rispetto all'utilizzo del metodo HTTP appropriato per quell'azione, anche se non è così elegante. Se vuoi vedere dove viene effettuata la chiamata di cancellazione devi solo cercare "api / entity / delete" e lo troverai subito.
La creazione di un'API senza l'intera gamma di metodi HTTP ne semplifica l'utilizzo e la manutenzione in seguito
Metodi sicuri: Ottieni risorsa / Nessuna modifica nella risorsa
Idempotente: Nessuna modifica nello stato della risorsa se richiesto molte volte
Metodi
non sicuri: Crea o aggiorna la risorsa / Modifica nella risorsa Non idempotente: Modifica nello stato della risorsa se richiesto più volte
Secondo il vostro requisito:
1) Per operazioni sicure e idempotenti (Fetch Resource) utilizzare --------- GET METHOD
2) Per operazioni non sicure e non idempotenti (Insert Resource) utilizzare --------- POST METHOD
3) Per operazioni non sicure e idempotenti (Aggiorna risorsa) utilizzare --------- METODO PUT
3) Per operazioni non sicure e idempotenti (Elimina risorsa) utilizzare --------- METODO DI CANCELLAZIONE