yumetodo/qiita_export_all

limitに達したときに、解除を待つ機能追加

Closed this issue · 4 comments

現状、大多数はAPI利用制限に無限に引っかかることはないと思うが、コメントが付いている記事を沢山投稿している人が利用すると無限に全件取得できない。Resume機能が必要か?

しかしどうやってテストするんだ?

Resume 機能は不要に1票

Resume 機能は「時間かかりそうだから残りは後日」的な目的があると思います。

もし、Resume 実装の目的が「API の利用制限回避」だとすれば、むしろ sleep をかます方向の方がいいかと。(実装もテストも楽だし)

単純なバックアップ目的であれば、多少時間がかかっても「放っておけばおk」の方がプライオリティは高めだからです。

利用制限
認証している状態ではユーザごとに1時間に1000回まで、認証していない状態ではIPアドレスごとに1時間に60回までリクエストを受け付けます。
利用制限 | Qiita API v2ドキュメント @ Qiita より)

このアプリはトークンを必須としているため、1,000 回/時が制限になります。

制限チェックのタイミングはわかりませんが、おそらく一度制限にかかると1時間は制限がかかると思われます。

代替案

  1. 一定数を取得したらクールダウン(sleep)時間を設ける
    • メリット: 記事数少なめなユーザに優位
    • デメリット:実装が煩雑になりそう
  2. 一件あたりの取得を遅くする(1件ごとに sleep を挟む)
    • メリット: 記事数関係なく安定
    • デメリット: 全体的に遅くなる

実はAPI叩いたときのResponceにはlimitが回復する時間が記されている(rate-reset)のでそれを見れば、一定数を取得したらクールダウン方式は可能ではあると思います。

$curl -sSL -D - -o /dev/null  "http://qiita.com/api/v2/users/yumetodo/items" -H "Authorization: Bearer $QIITA_ACCESS_TOKEN" -H "charset: utf-8" 
HTTP/1.1 301 Moved Permanently
Date: Sat, 07 Mar 2020 10:03:00 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Server: nginx
Location: https://qiita.com/api/v2/users/yumetodo/items
X-Request-Id: ed273d3c-597e-42bd-925c-9cc52c56df36

HTTP/2 200 
date: Sat, 07 Mar 2020 10:03:01 GMT
content-type: application/json; charset=utf-8
server: nginx
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
link: <https://qiita.com/api/v2/users/yumetodo/items?page=1>; rel="first", <https://qiita.com/api/v2/users/yumetodo/items?page=2>; rel="next", <https://qiita.com/api/v2/users/yumetodo/items?page=6>; rel="last"
total-count: 110
etag: W/"a8ec3185f8e4881c1ad0010d59af19bc"
cache-control: max-age=0, private, must-revalidate
rate-limit: 1000
rate-remaining: 416
rate-reset: 1583576862
vary: Origin
x-runtime: 0.297823
strict-transport-security: max-age=2592000
x-request-id: 13f6173a-6285-4b50-81e6-023e7c871222

Responceにはlimitが回復する時間が記されている(rate-reset)

なるほど。rate-remaining を見ながらある程度取得して、rate-reset を過ぎるまで待機という方法もあるかもしれませんね。

7506736 で解決