HTMLフォームにPUTおよびDELETEメソッドがないのはなぜですか？

HTML4 / XHTML1はフォームでGETとPOSTのみを許可しますが、HTML5も同じように見えるようになりました。これら2つを追加する提案がありますが、勢いを増しているようには見えません。HTML5仕様ドラフトにPUTとDELETEを含めない技術的または政治的な理由は何ですか？

これは興味深い質問です。ここでの他の答えはすべて投機的であり、場合によっては完全に間違っています。ここで意見を書く代わりに、実際にいくつかの調査を行い、deleteとputがHTML5フォーム標準の一部ではない理由を説明する元のソースを見つけました。

結局のところ、これらのメソッドはいくつかの初期のHTML5ドラフト（！）に含まれていましたが、その後のドラフトでは削除されました。Mozillaは実際にこれをFirefoxベータ版でも実装していました。

これらのメソッドをドラフトから削除する理由は何ですか？W3Cは、バグレポート10671でこのトピックについて議論しました。マイク・アムンセンはこのサポートを支持して主張しました：

XmlHttpRequestオブジェクトを使用する最新のWebブラウザーでは、PUTおよびDELETEを実行してオリジンサーバー上のリソースを変更するのは簡単です。スクリプト化されていないブラウザインタラクションの場合、これはそれほど単純ではありません。[...]

このパターンは非常に頻繁に必要とされるため、一般的に使用されるいくつかのWebフレームワーク/ライブラリが「組み込み」の回避策を作成します。[...]

その他の考慮事項：

• PUT / DELETEを使用する代わりにPOSTをトンネルとして使用すると、キャッシュの不一致が発生する可能性があります（POST応答はキャッシュ可能、PUT応答はnot（6）、DELETE応答はnot（7））
• 非べき等メソッド（POST）を使用してべき等操作（PUT / DELETE）を実行すると、ネットワーク障害（たとえば、「このアクションを繰り返しても安全ですか？」）による回復が複雑になります。
• [...]

彼の投稿全体を読む価値があります。

トムウォードロップも興味深いポイントを挙げています。

HTMLはHTTPと密接に結びついています。HTMLはHTTPのヒューマンインターフェイスです。したがって、HTMLがHTTP仕様のすべての関連メソッドをサポートしていない理由は、自動的に疑問視されます。マシンがリソースをPUTおよびDELETEできるのに、人間はできないのはなぜですか？[...]

セマンティックマークアップを保証するためにHTMLが非常に長くなる一方で、セマンティックHTTPリクエストを保証するための努力をこれまで行っていなかったことは矛盾しています。

バグは最終的に、次の理由でIan HicksonによってWo n't Fixとしてクローズされました。

フォームメソッドとしてのPUTは意味がありません。フォームペイロードをPUTしたくないでしょう。DELETEは、ペイロードがない場合にのみ意味があるため、フォームでもあまり意味がありません。

しかし、それで話は終わりではありません！この問題はW3Cバグトラッカーでクローズされ、HTMLワーキンググループの問題トラッカーにエスカレーションされました。

https://www.w3.org/html/wg/tracker/issues/195

この時点で、これらのメソッドがサポートされていない主な理由は、そのための包括的な仕様を作成するのに時間をかけた人がいないためだと思われます。

GETとPOSTには、明確なコンテンツ中立的な根拠があります。GETは、URLのコンテンツを、安全に繰り返しキャッシュできる方法で取得することです。POSTは、繰り返し、投機的に実行、またはキャッシュするのが安全でない方法で何かをすることです。

PUTまたはDELETEに類似した根拠はありませんでした。両方ともPOSTで完全にカバーされています。リソースの作成または破棄は、繰り返し実行するのが安全ではなく、投機的に実行するのが安全ではない操作であり、キャッシュしないでください。追加の特別なセマンティクスは必要ありません。

したがって、基本的に利点はありません。

これは、バグ10671がフォームメソッドとしてPUTおよびDELETEのサポートを追加することを検討しているため、2010年に発生しました。

この「機能」といくらかの利き手については中程度のプッシュバックがありましたが、最終的にはワーキンググループバグトラッカーの2つの問題としてエスカレートされました。

• 問題195：フォームからのHTTPリクエスト生成を強化
• ISSUE-196：ユーザーエージェントのHTTP応答処理動作を定義する

ISSUE-196の問題により、HTML仕様では現在POSTリクエストへの応答の処理方法が制限されていないため、仕様に変更を加えないという合意に至りました。この特定の問題は、一般的に使用されているPOSTリダイレクトパターンと、ReSTfulサーバーがブラウザーでレンダリングするのに役立つものではなく、短いメッセージで2xx応答を提供する方法を調整しようとするときに発生したと考えられます。

ISSUE-195の問題が議長に提出されました。キャメロン・ジョーンズは、2012年1月18日にボランティアとして変更提案書を作成し、2014年5月29日に最初のワーキングドラフトとして提出しました。ドラフトはW3C勧告プロセスを経ます。

運が良ければ、これはまもなくW3Cの推奨事項になり、ブラウザベンダーによって実装され、ブロッカーを削除して、統一されたセマンティックでブラウザフレンドリーなReSTfulサービスを作成するための大きな前進ステップになります。これは、サービスパターンの興味深い進化を引き起こすと思います。Jon Mooreによる良い講演があります-見る価値のあるハイパーメディアAPI、これは私の興味を引きましたが、最初のハードル（このハードル）で落ちました。

私の理解では、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月）はHTTP 1.0（1996年5月）より前 に指定されたことに留意してください。したがって、誰もがGET（HTTP 0.9以降）または拡張機能POSTでのみHTTPを使用していました。ただし、PUTおよびDELETEをサポートしているWebサーバーはごくわずかです（HTTP 1.0付録に記載されているように）。

考え

Berners-LeeのセマンティックWebの開発がどのように進化したのかを考えると、実際の問題から一般的な概念に移行したことが明らかです。最初に彼はドキュメントを共有したかった。そのため、マークアップが必要でした。次に、データベースでコンテンツを照会したかったので、フォームが必要でした。それから彼は新しいデータをデータベースに入れたかった。そこで彼はGETとPOSTでフォームを使用しました。その後、彼はリモートからのデータに対してすべてのCRUD操作を実行できることに気付いた可能性があるため、HTTPが拡張されましたが、遅すぎたためHTMLは拡張されませんでした（新しいCRUD操作をサポートしたサーバーはわずかでした）。

単なる推測を投げ捨てますが、おそらく、HTTPはアクセス制御が最高の状態でひどく良くないためであり、誰もが最後に必要とするのは、悪意のあるURLがセキュリティが不十分なWebサイトやアプリケーションを侵害するさらに多くの方法です。

HTTPは、サーバーからクライアントへのダウンロード以外のファイル転送に適したプロトコルではありません。FTPを使用します-またはそれ以上、SFTP。

GetとPostは、リクエストのデータを送信する形式です。

私はあなたがRESTFULサービスにフォームを送信することについて尋ねていると思います。ただし、httpリクエストの標準を変更して、httpリクエストの目的を仮定することは意味がありません。要求が満たされる目的に関する情報は、入力フィールドで最適に処理されます。

アドレスとgetおよびpostがあれば、サーバーはリクエストとその入力値を正しく解釈できます。そこから入力値を使用すると、サーバーに対してオープンエンドのリクエストを行い、必要な処理を実行できます。たとえば、値が「put」および「delete」であるフィールドを持つことができます