2

RESTful 検索への標準的なアプローチは次のとおりだと思います。

GET /users?parameter1=value1&parameter2=value2&parameter3=value3&parameter4=value4

しかし、私はこのようなことをしたい:

GET /users
# Request body:
{
    "parameter1": "value1",
    "parameter2": "value2",
    "parameter3": "value3",
    "parameter4": "value4"
}

更新: 一部のデバイスは GET 要求の本文コンテンツを尊重しないため、上記の方法で GET を使用することはできません。したがって、代わりに POST を使用する必要があります。

/api/searchURI を使用するのではなく 、JSON データをエンドポイントに送信するために POST を使用してはならない唯一の理由は、RESTful な宗教性ですか?

この方法で POST を使用することには、技術的かつ明白な危険がありますか?

これが次のようなものであることは承知しています。

RESTful な検索/フィルタリングを設計するには?

しかし、私はもっと具体的なことを尋ねています。つまり、「慣習に合わない」以外に、これが悪いアプローチになる理由は何ですか。

4

1 に答える 1

6

これを行うには、POST を使用できます。HTTP 仕様では禁止されていません。

GET を使用すると、リクエストの特性をより正確に表すことができます。POST を使用する場合、仲介者は、安全で冪等な要求を実行しているとは言えません。これにより、特定の仲介業者から得られる利益が制限される可能性があります。POST を使用して、キャッシュされた応答を利用することはできません。

これらのメリットの損失が、よりクリーンな URI を使用することで得られるメリットを上回らないと思われる場合は、POST を使用してください。

正当な理由もなく POST over GET を使用する習慣をつけないことをお勧めします。

また、6 か月後に検索への応答をキャッシュできることを本当に望んでいる場合は、いつでもサーバーの応答をリダイレクトに変更して、クライアントがロケーション URI にエンコードされたパラメーターを持つ GET でリダイレクトできることを認識してください。その後、キャッシュされた結果を利用できます。

重要なことは、真実ではないセマンティクスを伝える Http メソッドを決して使用してはならないということです。つまり、安全でないことを行うために GET を使用しないでください。べき等でないことを行うために PUT を使用しないでください。ただし、POST はリクエストを制限しないため、常に POST を使用できます。仲介者が POST を支援するためにできることはあまりないことに注意してください。

于 2013-06-18T21:44:40.733 に答える