174

私が関与している大規模なソーシャル ネットワーキング Web サイト用の REST API サービスを開発しています。これまでのところ、うまく機能しています。GET、POST、PUTおよびDELETEリクエストをオブジェクト URL に発行して、データに影響を与えることができます。ただし、このデータはページングされます (一度に 30 件の結果に制限されます)。

ただし、API を介して、たとえばメンバーの総数を取得するための最良の RESTful な方法は何でしょうか?

現在、次のような URL 構造にリクエストを発行しています。

  • /api/members — メンバーのリストを返します (上記のように一度に 30 個)
  • /api/members/1 — 使用されるリクエスト方法に応じて、単一のメンバーに影響します

私の質問は、同様の URL 構造を使用して、アプリケーション内のメンバーの総数を取得するにはどうすればよいですか? 明らかに、idフィールドのみを要求して (Facebook の Graph API と同様)、結果をカウントしても、30 個の結果のスライスしか返されないため、効果がありません。

4

13 に答える 13

93

/API/users への応答はページングされ、30 レコードしか返されませんが、応答にレコードの総数や、ページ サイズ、ページ番号/オフセットなどのその他の関連情報を含めることを妨げるものは何もありません。 .

StackOverflow API は、同じ設計の良い例です。Users メソッドのドキュメントは次のとおりです - https://api.stackexchange.com/docs/users

于 2010-09-15T08:48:32.637 に答える
24

HEADリクエストに応答して、カスタムHTTPヘッダーとしてカウントを返すことができます。このように、クライアントがカウントのみを必要とする場合、実際のリストを返す必要はなく、追加のURLも必要ありません。

（または、エンドポイントからエンドポイントまで制御された環境にいる場合は、COUNTなどのカスタムHTTP動詞を使用できます。）

于 2010-09-15T08:57:07.000 に答える
15

次のように、同じヘッダーを追加することをお勧めします。

HTTP/1.1 200

Pagination-Count: 100
Pagination-Page: 5
Pagination-Limit: 20
Content-Type: application/json

[
  {
    "id": 10,
    "name": "shirt",
    "color": "red",
    "price": "$23"
  },
  {
    "id": 11,
    "name": "shirt",
    "color": "blue",
    "price": "$25"
  }
]

詳細については、以下を参照してください。

https://github.com/adnan-kamili/rest-api-response-format

swagger ファイルの場合:

https://github.com/adnan-kamili/swagger-response-template

于 2016-08-02T13:42:37.517 に答える
3

Member.Count() を呼び出して結果を返す新しいエンドポイント > /api/members/count についてはどうですか

于 2010-09-15T08:45:20.697 に答える
3

を追加するのが最も簡単なようです

GET
/api/members/count

メンバーの総数を返します

于 2010-09-15T08:46:15.470 に答える
0

複数のオブジェクトのカウントを返すための REST API の設計に関する興味深い議論: https://groups.google.com/g/api-craft/c/qbI2QRrpFew/m/h30DYnrqEwAJ?pli=1

API コンシューマとして、カウント可能なリソースのサブリソース (つまり、タスクのカウントの GET /tasks/count) として、または関係するメタデータのより大きな集約のフィールドとして、各カウント値が表されることを期待します。リソース (つまり、GET /tasks/metadata)。関連するエンドポイントを同じ親リソース (つまり /tasks) の下でスコープすることにより、API は直感的になり、エンドポイントの目的は (通常) そのパスと HTTP メソッドから推測できます。

追加の考え:

  1. 個々のカウントが他のカウントと組み合わせてのみ有効な場合 (統計ダッシュボードなど)、すべてのカウントを一度に集計して返す単一のエンドポイントを公開できます。
  2. すべてのリソースを一覧表示するための既存のエンドポイント (つまり、すべてのタスクを一覧表示するための GET /tasks ) がある場合、HTTP ヘッダーまたは応答本文のいずれかで、メタデータとしてカウントを応答に含めることができます。これを行うと、API に不要な負荷がかかりますが、ユース ケースによっては無視できる場合があります。
于 2020-10-27T11:24:33.153 に答える
-1

When requesting paginated data, you know (by explicit page size parameter value or default page size value) the page size, so you know if you got all data in response or not. When there is less data in response than is a page size, then you got whole data. When a full page is returned, you have to ask again for another page.

I prefer have separate endpoint for count (or same endpoint with parameter countOnly). Because you could prepare end user for long/time consuming process by showing properly initiated progressbar.

If you want to return datasize in each response, there should be pageSize, offset mentionded as well. To be honest the best way is to repeat a request filters too. But the response became very complex. So, I prefer dedicated endpoint to return count. 

<data>
  <originalRequest>
    <filter/>
    <filter/>
  </originalReqeust>
  <totalRecordCount/>
  <pageSize/>
  <offset/>
  <list>
     <item/>
     <item/>
  </list>
</data>

Couleage of mine, prefer a countOnly parameter to existing endpoint. So, when specified the response contains metadata only.

endpoint?filter=value

<data>
  <count/>
  <list>
    <item/>
    ...
  </list>
</data>

endpoint?filter=value&countOnly=true

<data>
  <count/>
  <!-- empty list -->
  <list/>
</data>
于 2014-07-18T09:19:31.080 に答える