Web API トレーニング 03 -エンドポイント設計編-

`もっと見る` データは絶対位置で取得する！

「もっと見る」「さらに読む」とか、追加データを取得したい、いわゆる
ページネーション について、実装面を考えてみる

相対位置っていうのは、先ほどの、「どこから、どこまでを」という条件データを元に、
相対的に決まるデータの位置のこと

どこから => offset, pageに該当
どこまで => limit, per-pageに該当

問題になるのはデータの取得量ではなく、取得するための位置検索条件が問題になる。

offsetの位置を最初から数える可能性がある。
図Aを見ると、例えば1000番目の記事を取得しようとして、1000番はどれだ…と、DBエンジンによっては
線形探索してしまうこともよくある。（あんまり調べてないけど、そういうのもあるらしい）
更新の激しいテーブルを使ってると、欲しいデータがずれる場合がある
図Bを見ると、1分前に取得した記事の場所が10番目にあったはずなのに、30秒後には12番目になってる
こういうことがあると、データを取得した先で個数の整合できずにアプリ落ちたり、ほしいデータが全然fetchできない、という状態になることもある（こっちが致命的かな）

//図Aかく
書いたら更新します・・・・！！！

//図Bかく
書いたら更新しますゆえ・・・！

データ自身を元に、絶対的に決まるデータの位置のこと
「どこから、どこまで」の指定を、 offset/limit で設定するのではなく、
「どのデータから、どこまで」の指定を、created_at/limit で設定する

例えば「データがつくられた日付 created_at から、 limit 分取得する」みたいに指定する。

絶対位置を使う利点は、相対位置の問題点を解決することにある

結局、一番致命的なのは「データのズレ」なので、
そこを解消するには、取得した最後のデータのうち、ユニークかつ時系列に取得可能なプロパティ を保存しておくのが大事

そのプロパティAは、ユニークで時系列なプロパティなので、そのプロパティA以降のプロパティB, C, Dと結びついた各データを狙い通りに取得できる。
テーブルの更新による影響を受けないのが一番利点かなと。

あとoffset使ってると、線形探索してしまうけど、プロパティAを用いると、インデックスさえ貼っておけばすぐに参照できるんじゃないかなと。

//図C作る
作りますうううう

クエリパラメータと、予めパスに仕込むパラメータの使い分けについて書きます