Windowsプログラムで作成する場合には、制限はそれほど考えなくてよさそうだ。

IPアドレスごとに利用制限を行います。
1日の利用上限は80,000または転送量上限400MByteです。
利用制限は初回アクセスから24時間が適用範囲です。
初回のアクセスから24時間後に回数と転送量を記録していたカウンタと
初回アクセス時刻をリセットします。

http://dev.syosetu.com/man/api/

遅延に関しては、もうあきらめるしかないが、制限は考える必要はなさそうだ。

取得するデータも最小限に抑えればいい。

なろうAPIを見ていると、なんとなく問題点が見えてくる。

話数別の更新日時が取得できない。そのために、メールなどでの告知ができないのだろう。あと、APIには”章”の考え方もない事から、機能として後付けされたのだろう。

フラグが大量に存在しているが、本来このフラグは種別分けされて処理されるべき物だろう。APIだからこうしているという考えもできるが、不自然な感じがしてしまう。フラグは、楽だからこうしていると思えばいいのだが、問題はポイントの取り扱い部分だ。APIの仕様を見てもいまいちはっきりとしたい。

日間ポイント
(ランキング集計時点から過去24時間以内で新たに登録されたブックマークや評価が対象)

週間ポイント
(ランキング集計時点から過去7日以内で新たに登録されたブックマークや評価が対象)

月間ポイント
(ランキング集計時点から過去30日以内で新たに登録されたブックマークや評価が対象)

四半期ポイント
(ランキング集計時点から過去90日以内で新たに登録されたブックマークや評価が対象)

年間ポイント
(ランキング集計時点から過去365日以内で新たに登録されたブックマークや評価が対象)

この部分だ。

”ランキング集計時点”の指定がないのだ。どこかに、保存してあれば、２４時間毎にデータを取得すれば履歴として使える。１時間毎にデータを取得すれば、時間ごとの集計が可能になる。しかし、この書き方だと、曖昧過ぎる。ランキング集計時点がシステムで決められているのなら、APIで取得できる数値は参考値になってしまう。参考値なら参考値で説明を追記してほしい。

あと説明が不親切。

novelupdated_at

小説の更新日時

general_lastup

最終掲載日 YYYY-MM-DD HH:MM:SSの形式

の違いに関して

novelupdated_at

小説の更新時刻 最後に小説データが更新された時刻です。

general_lastup

小説最終掲載日です。小説を公開した時点で反映されます。 上のgeneral_firstupと違い連載小説の場合、次話投稿時にも反映されます。ただし編集の場合は反映されません。

と説明されています。

特に、二つ目はひどいです。

”小説を公開した時点で繁栄されます”と”次話投稿時にも反映されます”となっています。ただし以降の書き方に関しては意味不明です。

データを取得して調べるしかないので、APIの調査は実際にプログラムを組んでみて調べるしかないと結論づけます。

はぁ・・・。

そもそも、更新通知をメールで投げてくれれば問題は解決するのに・・・SPAMにでも指定されたから止めたのか？

それとも単純に、メールで告知して小説を読まれると、広告が表示されなくてクリックされないから、作らなかったのか？

ユーザビリティが他の投稿サイトに追い越されて行ってしまっているように感じてしまう。