GETリクエストと一緒にリクエスト本文を渡すことはRESTスタイルのアプローチに反しませんか?
たとえば、Elasticsearchで情報をフィルタリングするには
curl localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'
一部のツールは、GETリクエストのリクエスト本文を回避するように設計されています(郵便配達員など)
[〜#〜] rfc [〜#〜] から:
GET要求メッセージ内のペイロードには、定義されたセマンティクスがありません。 GETリクエストでペイロード本体を送信すると、既存の実装によってはリクエストが拒否される場合があります。
言い換えれば、それは禁止されていませんが、未定義の動作であり、避けるべきです。 HTTPクライアント、サーバー、プロキシは自由に本文を削除できますが、これは標準に反しません。それは絶対に悪い習慣です。
HTTPBisワーキンググループ(HTTPおよび関連標準に取り組んでいるグループ)からの追加テキスト:
最後に、HTTPではGETリクエストに構文的に本文を持たせることができますが、これはパーサーを汎用的にするためだけに行われます。 RFC7231、セクション4.3.1のとおり、GETの本文には意味がなく、汎用HTTPソフトウェアによって無視されるか拒否されます。
いいえ、ちがいます。
RESTでは、POST
を使用してクエリを実行しても意味がありません。 POST
はサーバーを変更することになっています。検索するときは、明らかにサーバーを変更しないでください。
GET
は非常によくここに適用されます。
たとえば、次を使用して検索を実行することの違いは何ですか?
GET /_search?q=foo
対
GET /_search
{
"query": {
"query_string": {
"query" : "foo"
}
}
}
どちらの場合でも、いくつかの結果を「GET」して戻します。サーバー側で状態を変更するつもりはありません。
だからこそ、GET
はURI内でクエリを渡すか、本文を使用するかにかかわらず、ここで完全に適用できると思います。
とはいえ、一部の言語とツールではそれが許可されていないことを認識しています。 RFCには、GET
を含む本文を含めることはできないと記載されていません。
したがって、elasticsearchはPOST
もサポートします。
この:
curl -XPOST localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'
同じように機能します。