BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース APIのバージョニングコスト

APIのバージョニングコスト

原文(投稿日:2013/12/01)へのリンク

コントラクトのバージョニングや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たちが開発した環境以外に適用できるだろうか? この相対的なコストの説明はあなたの経験と合っているだろうか? 彼らがカバーしていないカテゴリはあるだろうか?

この記事に星をつける

おすすめ度
スタイル

BT