このトピックでは、Google API で使用されるバージョニング戦略について説明します。通常、これらの戦略はすべての Google マネージド サービスに適用されます。
API に下位互換性のない(互換性を「破る」)変更を加える必要が生じることがあります。このような変更が原因で、元の機能で依存関係があるコードの問題や障害が発生する可能性があります。
Google API はバージョニング スキームを使用して、互換性を破る変更を防止します。さらに、Google API は、アルファ コンポーネントやベータ コンポーネントなど、特定の安定性レベルでのみ利用可能な一部の機能を提供します。
ガイダンス
すべての Google API インターフェースは、メジャー バージョン番号(protobuf パッケージの最後にエンコードされ、REST API の URI パスの最初の部分として含まれます)を提供する必要があります。API でフィールドの削除や名前変更など、互換性のない変更が行われた場合は、既存のユーザーコードが突然破損しないように、API のバージョン番号を増やす必要があります。
API の新しいメジャー バージョンは、同じ API の以前のメジャー バージョンに依存してはいけません。呼び出し元は、その API に関連する依存関係と安定性のリスクを理解していることを期待して、API は他の API に依存する場合があります。このシナリオでは、安定した API バージョンは他の API の安定したバージョンにのみ依存する必要があります。
同じ API の異なるバージョンは、適切な移行期間にわたって、単一のクライアント アプリケーション内で同時に動作できる必要があります。この期間により、クライアントは新しいバージョンにスムーズに移行できます。古いバージョンは、シャットダウンされる前に、十分に伝達された適切な非推奨期間を経過する必要があります。
アルファ版またはベータ版の安定性のリリースを行う場合、API では、protobuf パッケージと URI パスのメジャー バージョン番号の後に、安定性レベルを次のいずれかの方法で追加する必要があります。
- チャンネル ベースのバージョニング(推奨)
- リリース ベースのバージョニング
- 公開設定ベースのバージョニング
チャンネル ベースのバージョニング
安定性チャンネルとは、インプレース更新を受け取る、指定された安定性レベルの長期リリースです。メジャー バージョンには、安定性レベルごとに複数のチャンネルはありません。この方法では、アルファ、ベータ、ステーブル の 3 つのチャンネルを使用できます。
アルファとベータのチャンネルは、安定性レベルをバージョンに追加しなければなりませんが、ステーブル チャンネルは安定性レベルを追加してはいけません。たとえば、ステーブル チャンネルでは、v1
は使用できるバージョンですが、v1beta
や v1alpha
は使用できません。同様に、v1beta
または v1alpha
は、ベータ チャンネルとアルファ チャンネルでは使用できるバージョンですが、v1
はどちらでも使用できません。これらの各チャンネルは新機能が追加されると「インプレース」で更新されます。
ベータ チャンネルの機能は、ステーブル チャンネルの機能のスーパーセットである必要があります。アルファ チャンネルの機能は、ベータ チャンネルの機能のスーパーセットである必要があります。
API 機能の廃止
API 要素(フィールド、メッセージ、RPC)は、これ以上使用しないことを示すため、どのチャンネルでも廃止予定にマークされる可能性があります。
// Represents a scroll. Books are preferred over scrolls.
message Scroll {
option deprecated = true;
// ...
}
廃止予定の API 機能は、アルファからベータへも、ベータからステーブルへも移行しません。つまり、どのチャンネルにも機能の「事前の廃止予定」は到着しません。
ベータ チャンネルの機能は、十分な期間廃止予定になった後に削除することができます。推奨期間は 180 日です。アルファ チャネルにのみ存在する機能の場合、廃止予定はオプションで、機能を予告なく削除することができます。削除する前に API のアルファ チャンネルで機能が廃止予定にされた場合、API は同じアノテーションを適用する必要があり、希望する任意の期間使用することができます。
リリース ベースのバージョニング
個々のリリースは、その機能が安定したチャネルに組み込まれる前の限られた期間に利用可能になることが予想されるアルファ版またはベータ版のリリースであり、その後、個々のリリースはシャットダウンされます。リリースベースのバージョニング管理戦略を使用する場合、API は各安定性レベルで任意の数の個別のリリースを持つことができます。
アルファとベータのリリースでは、安定性レベルがバージョンに追加され、リリース番号がインクリメントされる必要があります。たとえば、v1beta1
や v1alpha5
です。API は、コメントなどのドキュメントで、これらのバージョンの時系列を記録する必要があります。
アルファまたはベータの各リリースは、下位互換性のある変更によってインプレースで更新される場合があります。ベータ リリースの場合、下位非互換性の更新は、リリース番号をインクリメントして新しいリリースを公開することで実現することが推奨されます。たとえば、現在のバージョンが v1beta1
の場合、次は v1beta2
がリリースされます。
アルファとベータのリリースは、機能がステーブル チャンネルに到達した後には、シャットダウンされる必要があります。アルファ リリースはいつでもシャット ダウンできますが、ベータ リリースではユーザーに合理的な移行期間を与えることが推奨されます。推奨期間は 180 日です。
公開設定ベースのバージョニング
API の公開設定は、Google API インフラストラクチャが提供する高度な機能です。これにより、API プロデューサーは 1 つの内部 API サーフェスから複数の外部 API ビューを公開でき、各ビューは次のような API 公開設定ラベルに関連付けられます。
import "google/api/visibility.proto";
message Resource {
string name = 1;
// Preview. Do not use this feature for production.
string display_name = 2
[(google.api.field_visibility).restriction = "PREVIEW"];
}
公開設定ラベルは、任意の API 要素のタグ付けに使用できる、大文字と小文字が区別される文字列です。慣例により、公開設定ラベルには常に大文字を使用する必要があります。上に示した例のように、明示的な公開設定ラベルが適用されていない限り、暗黙的な PUBLIC
ラベルがすべての API 要素に適用されます。
各公開設定ラベルは許可リストです。API プロデューサーは、ラベルに関連付けられた API 機能を使用できるように、API コンシューマーに公開設定ラベルを付与する必要があります。つまり、API 公開設定ラベルは ACL の API バージョンのようなものです。
複数の公開設定ラベルを、カンマ区切りの文字列("PREVIEW,TRUSTED_TESTER"
など)を使用して 1 つの要素に適用できます。複数の公開設定ラベルが使用されている場合、クライアントは公開設定ラベルの 1 つ(論理 OR
)のみを必要とします。
1 つの API リクエストには 1 つの公開設定ラベルのみを使用できます。デフォルトでは、API コンシューマーに付与されている公開設定ラベルが使用されます。クライアントは、次のように明示的な公開設定ラベルを使用してリクエストを送信できます。
GET /v1/projects/my-project/topics HTTP/1.1
Host: pubsub.googleapis.com
Authorization: Bearer y29....
X-Goog-Visibilities: PREVIEW
API プロデューサーは、API のバージョニングに INTERNAL
や PREVIEW
などの API の公開設定を使用できます。新しい API 機能は INTERNAL
ラベルで始まり、PREVIEW
ラベルに移動します。機能が安定し、一般提供になると、API 公開設定ラベルはすべて API 定義から削除されます。
一般に、API の公開設定は増分変更に対する API のバージョニングと比較して実装が容易ですが、高度な API インフラストラクチャのサポートに依存します。Google Cloud APIs では多くの場合、プレビュー機能に API の公開設定が使用されます。