2

私たちは REST API を持っており、REST の精神に固執するのにかなりの成果を上げています。しかし、重要な消費者がいて、データストアを調整する方法を要求しています。フローは次のように機能します。

  1. 消費者は、日付範囲内に作成されたすべての在庫オブジェクトを取得するために GET 呼び出しを行います。これが 100 万の在庫 VIN を返すとしましょう。
  2. コンシューマーがペイロードを独自のデータストアと比較すると、5,000 個のインベントリ オブジェクトが欠落していることがわかります
  3. 消費者は、5,000 個の VIN ID を使用してリクエストを行い、それらの 5,000 個のオブジェクトを返したいと考えています。

問題は、長いクエリ文字列 (vin の JSON 配列) が、サーバーによって課されたクエリ文字列の長さの制限にぶつかることです。考えられるアイデア - 5k の個別の呼び出しを行う (恐ろしいように思える)、サーバーのクエリ文字列の長さの制限を増やす (これを行いたくない)、代わりに POST を使用する (RESTful ではない?)。

それで、ロイ・フィールディングが何をするのか気になります...

4

4 に答える 4

3

POSTid のリストを含む JSON ファイルを、たとえば という名前の新しいリソースに送信するのはどう/inventory/differenceですか?

計算に時間がかかる場合は、202 Accepted生成されたリソースの と id を使用して応答し、 でそれを指すことができ/inventory/difference/:idます。

于 2012-08-30T16:59:07.357 に答える
2

moonwave99が提案したものとやや似ていますが、代わりに「セット」と呼ばれるリソースを作成します。

セットに入れたい識別子のリストを/setにPOSTします。POSTの結果は、特定のセットに名前を付けるリソースへのリダイレクトURLです。

それで：

POST /set

結果：

301 Moved Permanently
Location: /set/123

それで：

GET /set/123

セット内のアイテムのリストを返します。

セットは「差異のフェッチ」のユースケースと直交しており、単にアイテムをまとめたものです。

セットの作成に時間がかかり、セット自体をデータのスナップショットと見なす場合、ユーザーがGET / set / 123を実行しようとすると、実際のデータセットが完了するまで、202Acceptedで応答できます。完了しました。

その後、次を使用できます。

GET /set/123/identifiers

たとえば、必要に応じて、セット内の実際の識別子のコレクションを取得します。

あなたは次のようなことをすることができます

POST /setfromquery

基準のリストを送信します（「John *」、city =「LosAngeles」などの名前）。これには、実際には独自の特定のリソースは必要ありません。クエリの「言語」を定義して、IDの単純なリストとおそらく他のフィルター基準の両方を含めるだけです。

演算（和集合、差など）を設定します。設定されたリソースを使用して、多くの強力な処理を実行できます。

最後に、もちろん、これまで人気のあるものがあります。

DELETE /set/123
于 2012-09-13T18:59:14.717 に答える
1

リクエストボディを必要とするリクエストに POST を使用して、リクエストボディを受け入れない GET を回避することで、誰もあなたを責めるとは思いません。あなたはただ実用的です。

5000 の個別のリクエストを作成したり、クエリ文字列の制限を引き上げたりするのは醜いです。POSTは前進する方法です。

于 2012-08-30T17:04:04.277 に答える
0

リソースを作成せずに投稿を使用するのは、私にはあまりにも汚いように思えました。最終的に、「チャンク」で要求される ID は 100 個に制限されるようにしました。実際には、これらのリクエストが 100 を超えることはめったにないため、REST の原則をハッキングしてエッジ ケースに対応することは、悪い考えのように思えました。制限がAPIドキュメントで明確に定義されていることを確認しました.doneとdone...

于 2012-09-13T18:15:24.930 に答える