10

今週初め、セマンティクス違反のようなことをしなければなりませんでした。説明させてください。

私は単純な AJAX クライアント アプリケーションを作成していました。これは、指定された数のパラメーターを使用してサービスに要求を行うことでした。アプリ全体が基本的に読み取り専用なので、HTTP GET を使用するのがよいと思いました。渡さなければならなかったパラメーターのいくつかは単純なものでした (ソート順やページ番号など)。

ただし、必要なパラメーターの 1 つが可変長である可能性があり、これが心配でした。GET リクエストのクエリ文字列内のすべてのパラメータをエンコードしていたので、リクエスト URL に対して (およそ) 2000 文字という不必要な上限が設定されているように思えました。いずれにせよ、私は 500 文字の長さのリクエスト URL を見るのが好きではありませんでした。

というわけで、POSTリクエストにはそのような制限がないので、切り替えることにしました。しかし、これは正しくありません。POST はデータの変更を意味するという印象を受けていますが、単純な読み取り専用リクエストに使用しています。

これを行うより良い方法はありますか？多くのパラメーターを使用して GET を実行するには? パラメータ自体の予備的な POST を実行してから、GET を実行するという 1 つの方法について聞いたことがあります。しかし、この技術には多くの要望が残されています。

しかし、この特定のケースを振り返ってみると、HTTP 要求メソッドの実際のセマンティクスと制限は何でしょうか? また、GET がどの種類のパラメーター ペイロードもサポートしていないのはなぜですか? URL でクエリ文字列を使用することは、私にはハックのように感じられます。

4

1 に答える 1

15

この問題に関するいくつかのポイント:

  • HTTP 仕様 (RFC 2616) では、GET 要求がパラメーターを持つことを禁止していないため、HTTP GET 自体のセマンティクスの問題ではありません。ただし、多くの HTTP スタック (クライアント、サービス、またはプロキシ用) は HTTP リクエストの本文を禁止しています。それらを使用できないという事実は、HTTP GET リクエストのセマンティックな問題よりも実装の詳細 (非常に一般的) です。
  • 同様に、URI (またはクエリ文字列) の長さの制限も RFC で指定されていません。これは主に、いくつかの HTTP サーバー スタックによって実装されるセキュリティの軽減策であり、悪意のあるクライアントがサーバー リソースを消費するのを防ぎます (たとえば、IIS/ASP.NET では既定の制限は 2k ですが、web.config のいくつかの要素を使用して増やすことができます)。繰り返しますが、これはセマンティックではなく実際的な問題です。
  • REST 哲学に従っている場合、POST 要求はデータの変更を示しますが、読み取り専用操作に使用される HTTP POST 要求の例は数多くあります。SOAP は、呼び出している操作が「安全」であるか「変更」であるかに関係なく、すべての要求で POST を使用します。したがって、これらの操作にも POST を使用できます。ただし、REST (および「正規の」HTTP) の使用法から逸脱すると、GET 要求には適用できても POST には適用できないキャッシングなど、プロトコルの機能の一部が失われます。
  • 2 つのリクエスト (パラメーター付きの POST + 結果を「取得」するための GET) を使用する例は、やり過ぎのようです。前述したように、POST リクエストは必ずしもリソースの変更を意味するわけではないため、1 つのリクエストで十分な場合は、操作にアクセスするために新しい「プロトコル」(POST+GET) を作成する必要はありません。
于 2012-06-10T05:41:19.853 に答える