私が構築しているページ分割された API の奇妙なエッジケースを処理するのに助けが欲しいです。
多くの API と同様に、この API は大きな結果をページ分けします。/foos をクエリすると、100 件の結果 (つまり、foo #1-100) と、foo #101-200 を返す /foos?page=2 へのリンクが返されます。
残念ながら、API コンシューマーが次のクエリを実行する前に foo #10 がデータ セットから削除されると、/foos?page=2 は 100 だけオフセットされ、foos #102-201 が返されます。
これは、すべての foo をプルしようとしている API コンシューマーにとって問題です。foo #101 を受信できないからです。
これを処理するベスト プラクティスは何ですか? できるだけ軽量にしたいと考えています (つまり、API リクエストのセッション処理を回避します)。他の API の例があれば、ぜひ教えてください。
ベストアンサー1
データがどのように処理されるかは完全にはわかりませんので、これが機能するかどうかはわかりませんが、タイムスタンプ フィールドを使用してページ分割することを検討しましたか?
/foos をクエリすると、100 件の結果が返されます。API は次のような結果を返すはずです (JSON を想定していますが、XML が必要な場合も同じ原則に従うことができます)。
{
"data" : [
{ data item 1 with all relevant fields },
{ data item 2 },
...
{ data item 100 }
],
"paging": {
"previous": "http://api.example.com/foo?since=TIMESTAMP1"
"next": "http://api.example.com/foo?since=TIMESTAMP2"
}
}
注意: タイムスタンプを 1 つだけ使用すると、結果に暗黙の「制限」が適用されます。明示的な制限を追加するか、プロパティを使用することをお勧めしますuntil。
タイムスタンプはリストの最後のデータ項目を使って動的に決定されます。これはFacebookのページ分割の仕組みとほぼ同じです。グラフAPI(一番下までスクロールすると、上記で示した形式のページネーション リンクが表示されます)。
1 つの問題は、データ項目を追加する場合に発生する可能性がありますが、説明に基づくと、それらは最後に追加されるようです (そうでない場合は、お知らせください。改善できるかどうかを確認します)。