URLクエリパラメータを使用したHTTP POST —良いアイデアかどうか？[閉まっている]

私はHTTPを経由するようにAPIを設計していて、HTTP POSTコマンドを使用するのかどうか疑問に思っていますが、URLクエリパラメータのみを使用し、リクエストボディを使用しないのが良い方法です。

考慮事項：

• 「優れたWebデザイン」では、POSTを介してべき等でないアクションを送信する必要があります。これはべき等ではないアクションです。
• リクエストパラメータがURLに含まれていると、このアプリの開発とデバッグが簡単になります。
• APIは、広範囲での使用を目的としていません。
• 本文なしでPOSTリクエストを行うと、少し作業が増えるようです。たとえば、Content-Length: 0ヘッダーを明示的に追加する必要があります。
• また、ボディのないPOSTは、ほとんどの開発者やHTTPフレームワークの期待に少し反しているようにも思えます。

リクエストの本文ではなく、URLクエリを介してPOSTリクエストでパラメーターを送信することに他に落とし穴や利点はありますか？

編集：これが検討されている理由は、操作がべき等ではなく、取得以外の副作用があるためです。HTTP仕様を参照してください。

特に、GETメソッドとHEADメソッドは、取得以外のアクションを実行することの重要性を持たないことが規約に定められています。これらの方法は「安全」であると考えられるべきです。これにより、ユーザーエージェントはPOST、PUT、DELETEなどの他のメソッドを特別な方法で表すことができ、ユーザーは安全でない可能性のあるアクションが要求されているという事実を知ることができます。

...

メソッドは、「偶数性」のプロパティを持つこともできます（エラーまたは期限切れの問題は別として）N> 0の同一リクエストの副作用は単一リクエストの場合と同じです。メソッドGET、HEAD、PUT、DELETEはこのプロパティを共有します。また、メソッドOPTIONSおよびTRACEには副作用がないため、本質的にべき等です。

アクションがべき等でない場合は、を使用する必要がありますPOST。そうでない場合は、問題を解決する必要があります。 GET、PUTおよびDELETE方法をされている必要冪等であることを。クライアントがGETサービスのすべての可能なリクエストをプリフェッチしていた場合にアプリケーションで何が起こるか想像してみてください。これがクライアントに見える副作用を引き起こす場合は、何かがおかしいです。

POSTクエリ文字列ありで本文なしでを送信するのは奇妙に思われることに同意しますが、状況によっては適切である可能性があると思います。

URLのクエリ部分は、現在のリクエストのスコープを制限するためのリソースへのコマンドと考えてください。通常、クエリ文字列はGETリクエストのソートやフィルタリングに使用されます（など?page=1&sort=title）がPOST、スコープを制限する（のように?action=delete&id=5）ことも意味があると思います。

誰もが正しい：非べき等のリクエストにはPOSTを使用します。

URIクエリ文字列とリクエストコンテンツの両方を使用するのはどうですか？まあそれは有効なHTTP（注1を参照）なので、なぜでしょうか。

また、完全に論理的です。クエリ文字列部分を含むURLは、リソースを見つけるためのものです。一方、HTTPメソッドの動詞（POST-とそのオプションのリクエストコンテンツ）は、アクションを指定するか、何を行うかを指定します。リソースのです。それらは、直交する問題でなければなりません。（しかし、これらはContentType = application / x-www-form-urlencodedの特殊なケースに対する美しく直交する問題ではありません。以下の注2を参照してください。）

注1：HTTP仕様（1.1）では、POSTまたはPUT要求を受け入れるHTTPサーバーに対して、クエリパラメーターとコンテンツが相互に排他的であることは述べられていません。したがって、どのサーバーでも自由に両方を受け入れることができます。つまり、サーバーを作成する場合、両方を受け入れることを選択するのを止めるものは何もありません（おそらく柔軟性のないフレームワークを除く）。通常、サーバーは必要なルールに従ってクエリ文字列を解釈できます。また、Content-Typeなどの他のヘッダーを参照する条件付きロジックでそれらを解釈することもできます。

注2：WebブラウザーがユーザーがWebアプリケーションにアクセスする主要な方法であり、application / x-www-form-urlencodedが投稿するContent-Typeである場合、そのContent-Typeのルールに従う必要があります。そして、application / x-www-form-urlencodedのルールはより具体的（そして率直に言って、珍しい）です。この場合、URIをリソースの場所ではなく、パラメータのセットとして解釈する必要があります。[これは、パワーロードが提起した有用性の同じポイントです。サーバーにコンテンツをPOSTするためにWebフォームを使用するのは難しい場合があること。少し違うだけで説明しました。]

注3：クエリ文字列はもともと何ですか？RFC 3986では、HTTPクエリ文字列を、リソースを検索する非階層的な方法として機能するURI部分として定義しています。

この質問をする読者が、良いRESTfulアーキテクチャとは何かを尋ねたい場合：RESTfulアーキテクチャパターンは、URIスキームが特定の方法で機能することを要求しません。RESTfulアーキテクチャは、リソースのキャッシュ可能性、リソース自体の設計（それらの動作、機能、表現）、べき等性が満たされているかどうかなど、システムの他のプロパティに関係しています。または、言い換えると、HTTPプロトコルとそのHTTPメソッド動詞のセットとの互換性が高い設計を実現します。:-)（言い換えると、RESTfulアーキテクチャーは、リソースの配置方法にあまり影響を与えません。）

最後の注記：クエリパラメータは、リソースの検索やコンテンツのエンコードではない他の目的で使用される場合があります。「PUT = true」や「POST = true」のようなクエリパラメータを見たことがありますか？これらは、PUTおよびPOSTメソッドの使用を許可しないブラウザーの回避策です。このようなパラメータは、（ワイヤ上の）URLのクエリ文字列の一部として見られているが、私は彼らがURLのクエリの一部ではないと主張している精神で。

理由はありますか？ここに一つあります：

Webフォームを使用して、GETとPOSTを組み合わせて使用​​するページにリクエストを送信することはできません。フォームのメソッドをGETに設定すると、すべてのパラメーターがクエリ文字列に含まれます。フォームのメソッドをPOSTに設定すると、すべてのパラメーターがリクエストの本文に含まれます。

出典：HTML 4.01標準、セクション17.13フォームの送信

プログラムの観点から見ると、クライアントの場合、パラメーターをパッケージ化してURLに追加し、POSTとGETを実行します。サーバー側では、ポストされたバイトではなく、クエリ文字列からのインバウンドパラメーターを評価します。基本的にはウォッシュです。

特定のクライアントプラットフォームがネットワークスタック内のPOSTおよびGETルーチンをどのように処理するか、およびWebサーバーがこれらの要求を処理する方法に利点/欠点があるかもしれません。実装によっては、1つのアプローチが他のアプローチより効率的である場合があります。それを知ることは、ここであなたの決定を導くでしょう。

それにもかかわらず、プログラマーの観点からは、本文にすべてのパラメーターを指定してPOSTを許可するか、URLにすべてのパラメーターを指定してGETを許可し、POST要求でURLパラメーターを明示的に無視することを好みます。それは混乱を避けます。

コンテンツペイロードをPOSTボディに制限したまま、URL上のリソースを特定するクエリ引数を持つことは、依然としてRESTfulであると思います。これにより、「何を送信するのか」の考慮事項が分離されているように見えます。対「私はそれを誰に送りますか？」。

RESTのキャンプは、我々はHTTP動詞を使用する方法を標準化するために使用できるいくつかの基本原則を持っています。これは、RESTful APIを構築するときに役立ちます。

簡単に言えば、GETは読み取り専用である必要があります。つまり、サーバーの状態には影響しません。POSTは、サーバー上にリソースを作成するために使用されます。PUTは、リソースを更新または作成するために使用されます。DELETEは、リソースを削除するために使用されます。

言い換えると、APIアクションがサーバーの状態を変更する場合、RESTはPOST / PUT / DELETEを使用するようにアドバイスしますが、GETは使用しないでください。

ユーザーエージェントは通常、複数のPOSTを実行することは悪いことであり、POSTの目的はサーバーの状態を変更すること（たとえば、チェックアウト時に商品の代金を支払う）であることを警告します。

好きなだけ頻繁に実行できるGET（べき等）と比較してください。

同意します。本文ではなくURLでデータを渡す場合は、GETリクエストを使用する方が安全です。POST + GETの概念全体に関するいくつかの追加ビューについては、この同様の質問をご覧ください。