APIはシステム間連携、特に自動化に用いられることが多いため、一旦仕様が決まるとなかなか変更が難しいものです。そのためついつい触らぬ神のたたりなしとばかりにAPIの利用する側でどうにかしようと考えてしまいがちです。
しかし海外の各サービスで提供されているサービスについて見てみると、積極的なアップデートが行われているのに気付かされます。APIのアップデート情報を提供しているのがAPI Changelogです。
Twitterの例
例えばTwitterのAPIを見てみた場合、ほぼ毎日のレベルで修正が行われているのが分かるでしょう。ロジック側の変更だけでなく、ドキュメントの修正も行われています。ドキュメントの訂正もあるでしょうが、その多くは仕様変更に伴う修正と思われます。
どんなメリットがあるのか
このような頻繁なアップデートのメリットとしてはAPIの開発がアジャイル的に、短いイテレーションの中で繰り返せるというメリットがあります。小さな変更を繰り返す形式は最近のシステム開発で取り入れられており、システム開発に伴う大きな問題である手戻りリスクを低減してくれます。
またシステムの大きな変更はそれに伴うリスク（起動しない、予期していなかったエラーが出るなど）も肥大化します。頻繁な変更とそれに伴うデプロイを行っているというのはそれだけリスクを低減できるはずです。
どんなデメリットがあるのか
最も大きいデメリットとしては仕様変更に伴う既存システムが動作しなくなることでしょう。バリデーションやパラメータの追加はこのリスクを含んでいます。この問題については自動テストを用意した上で、後方互換性を維持できるようにしなければなりません。
また、API連携の場合は無休で動き続けるケースが多いので、ゼロタイムなダウンタイムでのデプロイができるようになっている必要があるかも知れません。または予めメンテナンス状態を用意し、API利用側はそのAPIを試した上で使わなければならないといった仕組みを考えておく必要があります。
API利用者側がすべきこと
ひるがえってAPI利用者側の立場で考えた場合、APIの更新情報もきちんと確認し続ける必要があるでしょう。とはいえ一年に一回あるかないか分からない更新に対して適切に対応するのも難しいのは事実です。そこでAPI Changelogのようなサービスを利用し、自分が使っているAPIについて更新情報を適切にフォローできるようにしておきましょう。
特に海外では突然サービスを停止してしまうことも多々あります。一度作ったら終わりではなく、定期的なステータスチェックに加えてサービス自体の継続性についても確認が必要でしょう。
APIは従来の全銀手順であったり、団体などが標準を定義している訳ではないので各企業が自由に設計、提供しています（OAuth2やRSS/Atomのように仕様が定まっているものもあります）。そのため変更もまた企業のビジネス環境の変化や時代に合わせて自由に行われます。
開発者としてはAPIを利用する上で彼らのエコシステムに入り込んでいます。だからこそアップデート情報にあわせて適切な対応、追従を行っていくべきでしょう。
