17

API を設計していますが、GET 要求で JSON ペイロードを送信しても問題ないでしょうか?

この他の質問Payloads of HTTP Request Methodsでは、このリンクに従って見つけることができます:

  • HEAD - 本体のセマンティクスが定義されていません。
  • GET - 本体のセマンティクスが定義されていません。
  • PUT - 本文がサポートされています。
  • POST - 本文対応。
  • DELETE - 本体のセマンティクスが定義されていません。
  • TRACE - 本文はサポートされていません。
  • オプション - ボディはサポートされていますが、セマンティクスはサポートされていません (おそらく将来的に)。

これは、ペイロードを含む GET リクエストを送信してはならないということですか? そうするリスクはありますか？

  • 一部の HTTP クライアント ライブラリがそのようなペイロードを送信できないのはどうですか?
  • または、Java API コードが特定のアプリケーション サーバーで移植できないのでしょうか?
  • 他に何か？

私は、ElasticSearch が GET 要求でそのようなペイロードを使用していることを発見しました。

$ curl -XGET 'http://localhost:9200/twitter/tweet/_search?routing=kimchy' -d '{
    "query": {
        "filtered" : {
            "query" : {
                "query_string" : {
                    "query" : "some query string here"
                }
            },
            "filter" : {
                "term" : { "user" : "kimchy" }
            }
        }
    }
}
'

それで、この人気のあるライブラリがそれを行い、誰も文句を言わないなら、おそらく私は同じことをすることができますか?

ところで、これが queryString パラメータと JSON ペイロードを混在させてもよいかどうかを知りたいですか? この ElasticSearch クエリとまったく同じです。もしそうなら、どの引数が queryString パラメータまたはペイロード パラメータであるべきかを知るためのルールはありますか?

ここで読み取ることができます: リクエスト本文を含む HTTP GET

GET リクエストに本文を含めることに関する Roy Fielding のコメント。

はい。つまり、どの HTTP 要求メッセージにもメッセージ本文を含めることが許可されているため、そのことを念頭に置いてメッセージを解析する必要があります。ただし、GET のサーバー セマンティクスは制限されているため、ボディが存在する場合でも、リクエストに対してセマンティックな意味はありません。解析に関する要件は、メソッドのセマンティクスに関する要件とは別のものです。

したがって、はい、GET を使用して本文を送信できますが、そうしても役に立ちません。

これは HTTP/1.1 の階層化された設計の一部であり、仕様が分割されると再び明確になります (作業中)。

....ロイ

私の意見では、queryParamまたはmatrixParamにうまく適合しない複雑なクエリをサーバーに送信することは理にかなっているからです。ElasticSearch API の設計者も同じことを考えていると思います...

次のように呼び出すことができる API を設計する予定です。

curl -XGET 'http://localhost:9000/documents/inbox?pageIndex=0&pageSize=10&sort=title'

curl -XGET 'http://localhost:9000/documents/trash?pageIndex=0&pageSize=10&sort=title'

curl -XGET 'http://localhost:9000/documents/search?pageIndex=0&pageSize=10&sort=title' -d '{
    "someSearchFilter1":"filterValue1",
    "someSearchFilter2":"filterValue2",
    "someSearchFilterList": ["filterValue3","xxx"]
    ... a lot more ...
}
'

それはあなたにはうまく見えますか？以上の考察に基づきます。

4

4 に答える 4

2

一般的な Web フレームワークである Google App Engine は、ペイロードを使用した HTTP GET リクエストの作成をサポートしない特別な URL フェッチ ライブラリを使用します。したがって、API を Google App Engine ユーザーに届けたい場合は、この動作を要求することはお勧めしません。

これに関する問題を Google でオープンしました。

于 2014-01-20T08:03:39.150 に答える
0

何かができるからといって、そうすべきだというわけではありません。これが腹立たしいほど同語に聞こえる場合は申し訳ありませんが、標準に関することは、それらが標準であるということです.HTTPは、最も確立された標準の1つです。それは完璧ではなく、多くの人がそれについて変更したいと思っていることがたくさんありますが、ほとんどの人がまだこのようなユースケースに URL パラメーターを使用しているという事実は、私にはそうではないことを十分に示しています.今すぐ信頼できる代替手段。

speedplane と Julian Reschke からの回答は、body/payload を使用した GET リクエストに依存している場合に壊れる 2 つの具体的な例を示しています。必要に応じて、他のユーザーとは異なる方法でアプリを作成することもできますが、Web は、標準がおそらく通常よりも真剣に取り扱われるべき領域の 1 つです。先駆者になりたくなる気持ちはわかりますが、どれだけ多くの Web サイトが存在し、どれだけ多くの Web プログラマーがそれらを構築して維持しているのかを考えてみてください。決定的に優れた方法があったとしたら、現在ではそれが本番環境で広く使用されている可能性が高いでしょう。

標準が機能するためには非常に多くの人々が同意しなければならないため、標準はゆっくりと変更されます。ルールに違反するアプリケーションがあると言っているのは正しいですが、別の回答に対するAetherusのコメントで言及されているように、それらが人々に頭痛の種を引き起こしていることに気付くでしょう。私は、このような問題に対して抵抗が最も少ない道を選ぶ傾向があります。本気でやろうと思えば、きっとできると思います。

于 2016-02-17T02:55:25.783 に答える