バックエンド・API・データ · 上級
インターフェースのバージョニング:壊さずに変更する方法
一行でいうと: インターフェースを公開した——コミットした。破壊的変更は新しいバージョン、重複期間、事前通知が必要だ。
破壊的変更と見なされるもの
フィールドやルートの削除、型の変更、オプショナルフィールドを必須にすること、既存の値の意味の変更、制限の強化。オプショナルフィールドの追加は壊さない——消費者が認識しないフィールドを無視する限り、これは文書化する価値があるルールだ。
移行を管理する方法
新しいバージョンを古いものと並行して動かし、誰がまだ古いものを使っているかを測定し、使用がゼロになるか十分な通知を与えた後にのみオフにする。
意味のある内容を持つ少数のバージョンは、小さな変更ごとのバージョンに勝る。すべての生きているバージョンは維持してテストすべきコードだ。
段階的な廃止
ドキュメントとレスポンスヘッダーで日付付きで削除予定としてフィールドとルートをマークする。アクティブな消費者に通知を送る。そして最後に、オフにする前に——「制御された暗闇」を実行する:数分間シャットダウンして、誰が叫ぶか見る。
さらに深く
ルートだけでなく、バージョンと消費者ごとの指標を保持する。それなしに、古いバージョンをオフにすることは賭けであり、傷を受ける人は自分の本番環境でそれを発見する——つまり、あなたに届く緊急の電話で。