コントラクトのバージョニングやAPI/サービスのバージョニングというのは、SOAベースのシステムにとって常に検討事項だ。互換性にまつわるインパクトのため、もしくはクライアント-サービスのガバナンスのために、それはまだサイエンスというよりもアートに近いものだ。貴重な経験をもたらす例がたくさんある（たとえば、REST周辺は極めて人気がある）。だが、Jean-Jacques Dubray氏の書いた記事は、この領域に科学的客観性をもたらそうとしている。
最近、API（あるいはWebサービス）のバージョニングコストを見積るよう頼まれました。私はこの見積りを共有することにしました。API/サービスのバージョニングにまつわるコストについて、多くの人がまだ理解していないと感じたためです。
JJ氏によると、調べていくうちに、APIの構築コストは、その後のバージョニングに使われたアプローチに依存していることがわかった。
理解すべき重要なポイントは、たとえAPI消費者に対するコストがあなたにとって小さく見えたとしても、それは純粋なコストではないということです。そこにはリスクがあります、混乱したプロジェクト計画、使えない予算。。。API変更を予期していない消費者にとって、変更は即座にビジネス価値を失うことにつながります。
続いて、この記事では、APIのバージョニングを3つのアプローチに分類している。（それぞれについて、詳しくは元の記事を参照。JJ氏がいかにコストの測定方法を定義したのかも含まれている）
- ノット型「すべてのAPI消費者は1つのバージョンに結びつけられており、そのAPIが変わると、すべての消費者は変更する必要がある。これは基本的に、消費者およびエコシステム全体にわたって、大きな波紋を引き起こす。」
- ポイントツーポイント型「サービスのすべてのバージョンは稼動したまま残され、消費者は必要に応じて、自ら移行する必要がある。稼動しているバージョン数が増加するにつれ、メンテナンスコストも増加する。」
- 互換性のあるバージョニング 「すべてのクライアントが同一の互換性のあるバージョンのAPI/サービスとやりとりする。」
これらの定義とJJ氏が述べる方程式を使って計算されたコストを前提とすると、相対的コストは以下のようにプロットできる（y軸はコストで、x軸はバージョン番号）。
JJ氏はこう語る。
[...] APIを変えるとき、すべての顧客にアップグレードを強制して、1つのバージョンにするのは、エコシステムに対して非常に高くつきます。メンテナンスを必要とするバージョンを複数持っておく方がよりよいのですが、各バージョンをアップグレードし続けたり、代わりに古いバージョンを運用し続けようとするのは、かなりのコストです。互換性のあるバージョニング戦略が最も効率がよいように思えます。
他の人はどう思うだろうか？ このAPIのバージョニングコスト計算は、JJたちが開発した環境以外に適用できるだろうか？ この相対的なコストの説明はあなたの経験と合っているだろうか？ 彼らがカバーしていないカテゴリはあるだろうか？