API経由でのデータ取得について

[turenne_y]

APIはWoWsだけでなく、WoTやWoWPなどWGとして提供されていますが、ここではWoWsに関して述べさせていただきます。

MODなど各種ツール開発者向けに公開されているAPIの取得データ件数上限についてです。

リクエストを投げてあげるとJSON形式でデータを返してくれるわけですが、ここで上限として100件という上限があります。

この条件をはずすことはできないのかと思います。

例えば、2019/05/01時点ですべての艦船データは350件となっており、１回のリクエストで全件取得はできません。

そのため、艦種ごとに取得するようにしていたのですが、駆逐艦のデータは111/350と100件を超えており、艦種だけの条件でも対応することはできなくなりました。

※駆逐艦データ取得時のGETリクエスト

https://api.worldofwarships.asia/wows/encyclopedia/ships/?application_id=`アプリケーションID`&type=Destroyer

プレーヤーデータなどデータの性質によっては上限を設ける必要はあるとおもいますが、艦船データの取得には不要ではないかと思います。

現在は国籍別にデータを取得した後で、マージしてロジックまわすようにしていますが、理想は１回で取得できる状態です

ユーザとしては提供された道具でうまくやるのが原則ですが、実際どうなんだろう？と思います。

[konjac_potage]

レコード数の多いデータを取得するAPIで1回のリクエストで取得できる件数を制限するのは自然な設計だと思います。

試しに条件なしで全フィールドを取得するリクエスト(?language=ja&limit=100)を投げてみましたが、レスポンスサイズは80KBもあり、サーバー側の処理時間(TTFB)が約600ms、ダウンロード時間が約350msで合わせて1リクエストに1秒近くもの時間がかかっています。

仮に上限を500件まで引き上げたとして、船が500隻まで増えると単純計算で1リクエストに5秒近く時間がかかることになり、どう考えても重すぎです。

APIのリクエスト数制限はこういった重めの処理のサーバーへの負荷を計算して設定してあるはずです。

Encyclopedia/Warships API はpage_noを指定することで101件目以降のデータも取得できるので、全ての艦のデータを取得するならこのオプションを使うことをお勧めします。

(実際にやると面倒くさいことは想像がつくので気持ちはわかります笑)

[turenne_y]

@konjac_potage さん、はじめまして

私はデータ巣取得用途ではバッチを作ってデータ取得をしています。

レスポンス計測をおこなった結果は @konjac_potage さんと同程度の平均0.8sでした。

500件で単純に5倍はさすがに乱暴だと思いますが、つくりによってはそれに準ずる時間がかかる可能性はあり得るでしょうね。

プロパティの数というよりは１件当たりの階層の複雑さが問題ですね。

複数テーブルから別々に取得するなり、joinして取得するなり、どちらにしても返却用の形式につめるのは大変だと思います。

WGの設計思想は聞いてみたいものです。

あと、頂いたアドバイスですが、正直おおきな違いがないと思います。

page_totalの回数だけリクエストを投げていた時期もありますが、「複数回リクエスト投げるなら同じじゃね？」ってことで現在に至ります。

 

[AnMoreNight]

XVMツールでWG-API鯖に負荷をかけている元凶の１人です(^0^;)

 

HTTPリクエストの回数が増えるとオーバーヘッドが増えるのでレスポンス時間が長くなりますから、気持ちは判りますww

でも、数多くあるstats提供サイト・statsツールなどからのリクエスト数は常時多いでしょうし、特にstatsサイトでは網羅的に大量のデータ取得を定期的にバッチ処理しているでしょうから、軟弱なWG-APIのDBサーバー性能ではリクエスト制限かけるしかないでしょうね・・・

サービスとして提供している程度のサーバーのDBキャッシュ増強とか処理分散とかは期待しても難しいでしょう(；´Д｀)

というわけで、仕方なくpage数でループするしかありません。艦艇データだけなら毎週変更が入るわけではないしGDPR対応的にも個人データではないので、ローカルファイルにキャッシュするのもひとつの方法です。

 

[turenne_y]

@AnMoreNightさん、はじめまして

ローカルファイルにキャッシュは盲点でした。

いろいろ考えましたが、結論としては時間を計測して３０件ほどがベストという結論でバッチ改修しました。

※トータルの時間は増えたが、改修の手間は発生しない

statusサイトが落ちてることはよくありますが、APIはしっかりレスポンス返してくれているので意外と信頼できるかもしれません