185

いくつかのフィルターに基づいて一連のオブジェクトを返す RESTful クエリ API を設計する必要があります。これに対する通常の HTTP メソッドは GET です。唯一の問題は、少なくとも 12 個のフィルターを持つことができ、それらすべてをクエリ パラメーターとして渡すと、URL がかなり長くなる可能性があることです (一部のファイアウォールによってブロックされるのに十分な長さです)。

パラメータの数を減らすことはオプションではありません。

私が考えることができる 1 つの代替手段は、URI で POST メソッドを使用し、フィルターを POST 本文の一部として送信することです。これは、RESTfull であること (データをクエリするために POST 呼び出しを行うこと) に反していますか。

より良いデザインの提案はありますか？

4

4 に答える 4

179

REST API の場合、すべては自分の視点の問題であることを忘れないでください。

REST API の 2 つの重要な概念は、エンドポイントとリソース (エンティティ) です。大まかに言えば、エンドポイントは GET を介してリソースを返すか、POST および PUT など (または上記の組み合わせ) を介してリソースを受け入れます。

POST を使用すると、送信したデータによって、新しいリソースとそれに関連付けられたエンドポイントが作成される場合とされない場合があり、POST された URL の下で「ライブ」しない可能性が高いことが認められています。つまり、POST を実行すると、処理のためにどこかにデータが送信されます。POST エンドポイントは、リソースが通常見つかる場所ではありません。

RFC 2616からの引用(無関係な部分を省略し、関連する部分を強調表示):

9.5ポスト

POST メソッドは、オリジン サーバーがリクエストに含まれるエンティティを、Request-Line の Request-URI で識別されるリソースの新しい従属として受け入れるように要求するために使用されます。POST は、統一されたメソッドで次の機能をカバーできるように設計されています。

  • ...
  • フォーム送信の結果など、データのブロックをデータ処理プロセスに提供する。
  • ...

...

POST メソッドによって実行されるアクションは、URI によって識別できるリソースにならない場合があります。この場合、応答に結果を説明するエンティティが含まれているかどうかに応じて、200 (OK) または 204 (コンテンツなし) のいずれかが適切な応答ステータスになります。

オリジンサーバーでリソースが作成されている場合、応答は 201 (Created) である必要があります...

私たちは、ユーザー、メッセージ、本など、問題のドメインが指示するものは何でも、「モノ」または「データ」を表すエンドポイントとリソースに慣れてきました。ただし、エンドポイントは別のリソース (検索結果など) を公開することもできます。

次の例を検討してください。

GET    /books?author=AUTHOR
POST   /books
PUT    /books/ID
DELETE /books/ID

これは典型的な REST CRUD です。ただし、次を追加するとどうなりますか。

POST /books/search

    {
        "keywords": "...",
        "yearRange": {"from": 1945, "to": 2003},
        "genre": "..."
    }

このエンドポイントには、RESTful でないものは何もありません。リクエストボディの形でデータ（エンティティ）を受け取ります。そのデータが検索基準であり、他の DTO と同様です。このエンドポイントは、リクエストに応じてリソース (エンティティ) を生成します: Search Results。検索結果リソースは一時的なものであり、リダイレクトなしで、他の正規 URL から公開されることなく、クライアントにすぐに提供されます。

エンティティが本ではないことを除いて、これはまだ REST です。リクエスト エンティティは本の検索条件であり、応答エンティティは本の検索結果です。

于 2015-08-13T09:32:04.517 に答える
90

多くの人が、長すぎる、または複雑すぎるクエリ文字列 (たとえば、クエリ文字列はネストされたデータを簡単に処理できない) を含む GET を POST として送信し、複雑な/長いデータを本文で表すという慣行を受け入れています。要求の。

HTTP 仕様で POST の仕様を調べます。とてつもなく広いです。(REST の抜け穴を通り抜けて戦艦を航行させたい場合は、POST を使用してください。)

GET セマンティクスの利点の一部を失います... GET はべき等であるため、自動再試行などですが、それを受け入れることができる場合は、POST で非常に長いクエリや複雑なクエリの処理を受け入れる方が簡単かもしれません。

（長い余談ですが...最近、HTTP仕様により、GETにドキュメント本文を含めることができることを発見しました。言い換えると、「このセクションにリストされているものを除いて、すべてのリクエストにドキュメント本文を含めることができます」というセクションがあります... HTTP 作成者がそれについて話しているスレッドを検索して見つけましたが、これは意図的なものであり、ルーターなどが異なるメッセージを区別する必要がないようにするためです.ただし、多くのインフラストラクチャ部分が GET の本体をドロップすることを実践してください。したがって、POST のように、本体で表されるフィルターを使用して GET を実行できますが、さいころを転がすことになります。)

于 2013-01-10T09:02:55.533 に答える