HTMLフォームにPUTおよびDELETEメソッドがないのはなぜですか？
HTML4/XHTML1はGETとPOSTのみ許可します。HTML5も同じように見えます。 追加する提案 がありますが、そうではありませんHTML5仕様ドラフトにPUTとDELETEを含めなかった技術的または政治的な理由は何でしたか？
これは興味深い質問です。ここでの他の答えはすべて推測であり、場合によっては、全体が正しくありません。ここに私の意見を書く代わりに、実際に調査を行ったところ、なぜdeleteおよびputがHTML5フォーム標準の一部ではないのかを説明する元のソースを見つけました。
結局のところ、これらのメソッドwereは いくつかの初期のHTML5ドラフト （！）に含まれていましたが、後で 後続のドラフト で削除されました。 Mozillaは実際にこれを実装しました Firefoxベータ版 も。
これらのメソッドをドラフトから削除する理由は何でしたか？ W3Cはこのトピックについて バグレポート10671 で説明しました。マイク・アムンセンはこの支持を支持して主張しました：
Originサーバー上のリソースを変更するためにPUTとDELETEを実行するのは、XmlHttpRequestオブジェクトを使用する最近のWebブラウザーでは簡単です。スクリプト化されていないブラウザの相互作用では、これはそれほど単純ではありません。 [...]
このパターンは頻繁に必要になるため、一般的に使用されているいくつかのWebフレームワーク/ライブラリが「組み込み」の回避策を作成しています。 [...]
その他の考慮事項：
- PUT/DELETEを使用する代わりにPOSTをトンネルとして使用すると、ミスマッチをキャッシュする可能性があります（例POST応答は cachable 、 PUT応答はnot（6）、DELETE応答はnot（7））
- べき等ではない方法（POST）を使用してべき等演算（PUT/DELETE）を実行すると、ネットワーク障害による復旧が複雑になります（「このアクションを繰り返しても安全ですか？」など）。
- [...]
彼の投稿全体を読む価値があります。
Tom Wardropも興味深い点を指摘しています。
HTMLはHTTPと密接に結びついています。 HTMLはHTTPのヒューマンインターフェイスです。したがって、HTMLがHTTP仕様のすべての関連メソッドをサポートしていない理由は自動的に疑われます。なぜリソースをPUTおよびDELETEできますが、人間はできないのですか？ [...]
HTMLがセマンティックマークアップを確実にするために非常に長い期間を費やしている一方で、セマンティックHTTPリクエストを確実にするためにこれまでそのような努力をしていなかったことは矛盾しています。
このバグは、Ian HicksonによってWo n't Fixとして最終的にクローズされましたが、次の根拠があります。
フォームメソッドとしてのPUTは意味をなさないため、フォームペイロードをPUTする必要はありません。 DELETEは、ペイロードがない場合にのみ意味があるため、フォームでもあまり意味がありません。
しかし、これで話は終わりではありません！この問題はW3Cバグトラッカーでクローズされ、escalatedがHTMLワーキンググループの問題トラッカーに送信されました。
https://www.w3.org/html/wg/tracker/issues/195
現時点では、これらのメソッドがサポートされていない主な理由は、誰もそれについて包括的な仕様を書くために時間をかけなかったということだけです
これは2010年に バグ10671がフォームメソッドとしてPUTおよびDELETEのサポートを追加することを検討する として提起されました。
この "機能"にはある程度の反発があり、強引になりましたが、最終的にはワーキンググループのバグトラッカーで2つの問題としてエスカレートされました。
問題 ISSUE-196 は、HTML仕様が現在のPOST要求の処理方法を制限していないため、仕様に変更を加えないことを決定しました。この特定の問題は、一般的に使用されているリダイレクトパターンPOSTリダイレクトパターンを調整する際に発生したものであり、ReSTfulサーバーがブラウザでのレンダリングに役立つものではなく、短いメッセージを含む2xx応答を提供する方法です。
問題 ISSUE-195 が議長に提示されました。 Cameron Jonesは、2014年5月29日に 最初の草案 になるように提出した2012年1月18日に変更提案を作成するボランティアにステップアップしました。草案は W3C推奨プロセス 。
運が良ければ、これはすぐにW3Cの推奨事項になり、ブラウザーベンダーによって実装されます。ブロッカーを削除して、統一されたセマンティックでブラウザーフレンドリーなReSTfulサービスを作成するための大きな前進となるでしょう。これは、sparkサービスパターンの興味深い進化だと思います。 Jon Moore-Hypermedia APIs による良い講演があります。これは、注目に値しますが、興味を引かれましたが、最初のハードル（これ）。
GETとPOSTには明確なコンテンツ中立の根拠があります。GETは、安全に繰り返し、おそらくキャッシュできる方法でURLのコンテンツを取得することです。POST =繰り返す、投機的に実行する、またはキャッシュするのが安全ではない方法で何かを行うことです。
PUTまたはDELETEには同様の根拠はありませんでした。どちらもPOSTで完全にカバーされています。リソースの作成または破棄は、繰り返すのが安全でなく、投機的に実行するのが安全ではない操作であり、キャッシュされるべきではありません。それらに必要な追加の特別なセマンティクスはありません。
したがって、基本的にはメリットはありません。
私の理解では、ブラウザはPUTまたはDELETEを送信した後、何をすべきかわからないということです。 POSTは通常、適切なページにリダイレクトしますが、PUTおよびDELETEは通常はリダイレクトしません。これにより、Webブラウザフォームからではなく、ajaxまたはネイティブプログラムを介した呼び出しに適しています。
私は今それを理解することはできませんが、私がhtml5メーリングリストの1つを読んで、これについて議論していたことを覚えています。
歴史
RFC1866（セクション8.1） でのHTMLフォームの最初の出現について言及する価値があると思います。ここで、メソッド属性は次のように定義されています。
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".
詳細な説明は セクション8.2.2-GET および セクション8.2.3-POST にあります。
HTML 2.0（1995年11月）がbeforeHTTP 1. （1996年5月）と指定されていることに注意してください。したがって、誰もがHTTPを使用するのはGET（HTTP 0.9以降）または拡張子POSTのみです。ただし、PUTとDELETEをサポートしているWebサーバーはごくわずかです（ HTTP 1.0付録 に記載されているように）。
考え
Berners-LeeによるセマンティックWebの開発がどのように進化したのかを考えると、それが実際の問題から一般的な概念に進んだことは明らかだと思われます。まず、ドキュメントを共有したいと考えました。したがって、マークアップが必要でした。次に、データベースにコンテンツを照会したかったため、フォームが必要でした。次に、彼は新しいデータをデータベースに入れたかった。そのため、GETとPOSTでフォームを使用しました。その後、リモートからのデータに対してすべてのCRUD操作を実行できることに気づいたかもしれません。そのため、HTTPは拡張されましたが、HTMLにはなりませんでした。