BSA / Managing APIs Over Multiple Releases

Managing APIs Over Multiple Releases †

要約 †

• APIを公開すること、システムを拡張したり統合するためのテクニックを公開することは、利用者に向けた公式なコミットメントになる
• 公開APIと内部APIではコミットメントの意味が違ってくる
• チーム内でしか利用しないAPIなら話は簡単
• 公開APIを変更するのはすさまじく難しい話になる
  • Webサービスがこの困難を解決するという噂もあったが信じられるわけがない
• システムは進化していくものなので、APIの進化を注意深く管理しなければならない

詳細な議論 †

APIの進化を管理するためのテクニックは次のとおり

十分すぎるくらい警告を出力する（誤訳ぅ…うるさすぎるくらいに告知する、でしょうか） †

• 統合や拡張に関係する変更をできる限り早く知ることができるようにしないといけない
• 今回のリリースで、次回リリースではこういう変更がありますよ、という告知をするのがよくあるやり方
• 古いAPIから新しいAPIへの移行を手助けする方法を提供するとかもあり
  • 古いAPIを特定したり、自動的に変換したりするツールを提供するなど

次のリリースまで共存期間を設ける †

• 新しいAPIを提供したリリースですぐに古いAPIを廃止するのではなく、その次のリリースまで共存できるようにしておく

後方互換性レイヤを設ける †

• プロダクトの基本的な機能は変わらないことを前提として、「サポート対象外」のAPI（レイヤ）を提供する
• ユーザーから、公式にサポートされているAPIだと誤解されてしまうことがある

廃止された API の呼び出し箇所を特定したり置き換えたりする用意する †

• そうすれば移行してもらいやすくなる

担当者のつぶやき †

誤訳ェ…

みんなの突っ込み †