- 新しいHTTPメソッド
QUERY を提案
- リクエスト時にコンテンツを送信できる、安全かつ冪等性(idempotent)のあるリクエストメソッド
- リクエストで渡すデータが大きすぎてURIにエンコードできない場合に利用可能
- クエリパラメータが数KB以上になると、多くの実装で制限が設けられている
- この制限をリクエスト前に把握できないことが多く、さらにエンコードが必要なため非効率
- そのため多くの実装では、GETの代わりにPOSTを使ってクエリを実行している
- ただし、サーバーについての具体的な知識がなければ、それが安全で冪等かどうかなどを判断できず、GETと同様の基本的な制約がある
QUERY メソッドは、GETとPOSTの使い分けの間にあるギャップを埋めるソリューションを提供
- POSTと同様に、クエリ処理への入力はリクエストURIの一部ではなく、リクエストのコンテンツ内で渡される
- しかしPOSTとは異なり、このメソッドは明示的に安全かつ冪等であり、キャッシュや自動リトライのような機能を利用できる
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
7件のコメント
なぜこれをプロトコルに追加する必要があるのか分かりません。
クエリパラメータが数KBを超えるようなシナリオは、そんなに多いのでしょうか?
https://www.baeldung.com/cs/http-get-with-body
HTTP仕様が読者に独自解釈の余地を与え、一貫性なく変化してきたため、いっそメソッドを新しく作ろうとしているように見えます
リクエストボディ付きのGET
一部のclient libraryでは、GETをリクエストする際にrequest bodyをまったく渡す手段がないこともありますが、その代替になりそうですね。
ライブラリ実装の観点から見ると、むしろさらに不要な標準変更の提案ではないでしょうか?
標準仕様上、GET はリクエストボディを持てないのに、ライブラリが任意にリクエストボディを渡しているわけですし……
それなら、ライブラリ側でカスタムメソッドを実装するだけでも問題ないのではないでしょうか?
必要性そのものを完全に否定するのは難しいですが、HTTP 1.0 から 1.1 に上がる際に追加された PUT、PATCH、DELETE などと比べると、説得力に欠けるように思います.
https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://elastic.co/guide/en/…
標準仕様では、GET Method の body に関する部分は明示していませんが、入れてはいけないと言ったことはありません。
サーバーフレームワークによっては GET Method で body を処理しない場合があるため、MDN では GET Method に body を入れないよう推奨しています。
Elasticsearch は GET Method で Body をサポートしています
ライブラリの実装によって仕様が変更されるべきなのかは、もう少し検討が必要ではないかと思います。