HTML4 / XHTML1 consente solo GET e POST nei moduli, ora sembra che HTML5 faccia lo stesso. C'è una proposta per aggiungere questi due ma non sembra che stia guadagnando trazione. Quali sono stati i motivi tecnici o politici per non aver incluso PUT e DELETE nella bozza delle specifiche HTML5?
Questa è una domanda affascinante. Le altre risposte qui sono tutte speculative e in alcuni casi non corrette. Invece di scrivere la mia opinione qui, ho effettivamente fatto qualche ricerca e ho trovato fonti originali che discutono sul perché delete e put non fanno parte dello standard del modulo HTML5.
Come risulta, questi metodi erano inclusi in diverse bozze iniziali HTML5 (!), ma successivamente sono state rimosse in bozze successive . Mozilla aveva effettivamente implementato questo in una versione beta di Firefox , anche.
Qual è stata la motivazione per la rimozione di questi metodi dalla bozza? Il W3C ha discusso questo argomento in rapporto sui bug 10671 . Mike Amundsen ha sostenuto a favore di questo supporto:
Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. [...]
This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]
Other considerations:
- Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, PUT responses are not(6), DELETE responses are not(7))
- Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").
- [...]
Vale la pena leggere il suo intero post.
Tom Wardrop fa anche un punto interessante:
HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]
It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.
Il bug è stato infine chiuso come Non sarà risolto da Ian Hickson, con le seguenti motivazioni:
PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.
Tuttavia, questa non è la fine della storia! Il problema è stato chiuso nel bug tracker del W3C e intensificato nel tracker dei problemi del gruppo di lavoro HTML:
A questo punto, sembra che il motivo principale per cui non c'è supporto per questi metodi è semplicemente che nessuno ha avuto il tempo di scrivere una specifica completa per questo.
GET e POST hanno una logica razionale neutra rispetto al contenuto. GET è quello di recuperare il contenuto di un URL in un modo che è sicuro da ripetere e possibilmente cache. POST è fare qualcosa in un modo che non è sicuro ripetere, eseguire in modo speculativo o cache.
Non c'era una logica simile per PUT o DELETE. Sono entrambi completamente coperti da POST. La creazione o la distruzione di una risorsa sono operazioni che non sono sicure da ripetere, non sicure da eseguire in modo speculativo e non devono essere memorizzate nella cache. Non ci sono ulteriori semantiche speciali necessarie per loro.
Quindi in pratica non ci sono vantaggi.
Questo è stato sollevato nel 2010 come Bug 10671 considera l'aggiunta del supporto per PUT e DELETE come metodi di modulo .
C'è stata una moderata quantità di pushback per questa "funzionalità" e un po 'di mano pesante, ma alla fine questa è stata escalation come due problemi sul bug tracker di Working Group:
Il problema NUMERO-196 ha portato a una decisione concreta di non apportare modifiche alle specifiche poiché le specifiche HTML non limitano attualmente il modo in cui vengono gestite le risposte alle richieste POST. Credo che questo particolare problema sia stato sollevato nel tentativo di riconciliare i pattern di reindirizzamento POST comunemente in uso e in che modo i server ReSTful spesso forniscono risposte 2xx con messaggi brevi piuttosto che qualcosa di utile da rendere in un browser.
Il problema NUMERO-195 è stato presentato alle sedie. Cameron Jones ha intensificato volontariato nella stesura di una proposta di modifica il 18 gennaio 2012 che ha presentato per diventare prima bozza di lavoro il 29 maggio 2014. La bozza passerà attraverso Processo di consigli del W3C .
Con un po 'di fortuna, questa sarà presto una raccomandazione del W3C e implementata dai produttori di browser, e sarebbe un grande passo in avanti nella rimozione dei blocchi per produrre servizi ReSTful unificati, semantici e ottimizzati per il browser. Immagino che questo accenda un'evoluzione interessante nei modelli di servizio. C'è una buona conversazione di Jon Moore - API Hypermedia che vale la pena guardare, questo ha suscitato il mio interesse ma è caduto al primo ostacolo (questo).
La mia comprensione è che i browser non sanno cosa fare una volta inviato un PUT o un DELETE. Un POST reindirizzerà di solito su una pagina appropriata, ma PUT e DELETE generalmente no. Questo li rende adatti per chiamare tramite ajax o un programma nativo, ma non da un modulo di browser Web.
Non riesco a tenerlo in questo momento, ma ricordo di aver letto una delle mailing list html5 quando stavano discutendo di questo.
Penso che valga la pena menzionare la prima apparizione dei moduli html nella RFC1866 (Sezione 8.1) . Qui l'attributo del metodo è definito come segue:
METHOD selects a method of accessing the action URI. The set of applicable methods is a function of the scheme of the action URI of the form. See 8.2.2, "Query Forms: METHOD=GET" and 8.2.3, "Forms with Side-Effects: METHOD=POST".
Ulteriori spiegazioni si trovano in Sezione 8.2.2 - GET e Sezione 8.2.3 - POST
Ricorda che HTML 2.0 (Nov. 1995) è stato specificato prima HTTP 1.0 (Maggio 1996). Quindi tutti usavano HTTP solo con GET (a partire da HTTP 0.9) o con l'estensione POST. Tuttavia, solo pochi server Web supportano PUT e DELETE (come indicato nella Appendice HTTP 1.0 ).
Se pensi a come lo sviluppo di Berners-Lee del web semantico potrebbe essersi evoluto, sembra chiaro che è passato da problemi reali a concetti generali. Prima voleva condividere i documenti. Quindi aveva bisogno del markup. Poi ha voluto interrogare i database per il contenuto, quindi aveva bisogno di moduli. Poi ha voluto inserire nuovi dati nel database. Quindi ha usato i moduli con GET e POST. Dopo di ciò, potrebbe aver capito che è possibile eseguire ogni operazione CRUD sui dati da remoto, quindi HTTP è stato esteso ma mai HTML perché era troppo tardi (solo pochi server supportavano le nuove operazioni CRUD).
Basta lanciare una supposizione selvaggia, ma probabilmente perché HTTP non è molto buono con il controllo degli accessi nel migliore dei casi, e l'ultima cosa di cui tutti hanno bisogno sono anche più modi per compromettere gli URL dannosi un sito web e / o un'applicazione poco sicura.
HTTP non è davvero un buon protocollo per i trasferimenti di file diversi dal download dal server al client. Usa FTP - o meglio ancora, SFTP.
Ricevi e pubblica sono formati di trasmissione dei dati della richiesta.
Suppongo che tu stia chiedendo di rendere l'invio di moduli in un servizio RESTFUL. Ma non ha senso cambiare lo standard di richiesta http per rendere le ipotesi lo scopo della richiesta http. Le informazioni sullo scopo della compilazione della richiesta vengono gestite nel modo migliore nei campi di input.
Avere un indirizzo e ricevere e post consente al server di interpretare la richiesta e i suoi valori di input correttamente. Da lì i valori di input ti permettono di fare richieste aperte al server e fare ciò che vuoi. Ad esempio, puoi avere un campo i cui valori sono "put" e "delete"