Looker API のバージョニング

ほとんどのアプリケーションは、なんらかの形式のクライアント SDK、または場合によっては API の URL を使用して記述されます。クライアント SDK と API の URL は、特定の Looker API バージョンにバインドされます。Looker が新しい API バージョンに変更を加えても、アプリケーションは引き続き機能します。新しい Looker API バージョンを使用するようにクライアント SDK をアップグレード(または API URL を変更)しない限り、アプリケーションは他の API バージョンの変更の影響を受けません。

Looker による API の変更

Looker API は、Looker API エンドポイントの安定性、つまりアプリケーションの安定性を提供するように設計されています。

Looker に多くの機能が追加されるのに伴い、Looker REST API も更新されて、新機能へのアクセスや管理ができるようになります。Looker の各リリースで、現行バージョンの Looker API に新しい API 関数、パラメータ、レスポンス タイプのプロパティを追加しています。ほとんどの場合、API に追加することで互換性を破る変更は行われないため、API で構築された既存のアプリケーション コードに影響を与えることなく、API の既存のバージョンを維持できます。既存のアプリケーション コードは、今後の Looker リリースに実装される新しい関数、パラメータ、または機能を気にしていない場合があります。

既存のアプリケーション コードを破損させる API の変更については、互換性を破る変更を新しい API バージョンにバンドルしています。つまり、古い API バージョンは以前と同じように動作しますが、変更や更新とともに新しい API バージョンも一緒に実行されます。1 つの Looker インスタンスに複数の API バージョンを並べて配置できるため、新しい API バージョンにアップグレードするタイミングを選択できます。古いエンドポイントを呼び出すためにビルドされた既存のコードは、引き続き古いエンドポイントを呼び出します。新しいコードは、最新バージョンの API で新しいバージョンのエンドポイントを呼び出します。

ただし、重大なセキュリティに関する問題の場合は例外です。Google は、API の特定の部分に関して重大なセキュリティ問題を発見した場合、そのセキュリティの問題をできるだけ早く軽減するために必要なあらゆる措置を講じます。これには、適切な機能が利用可能になるまで脆弱な機能を無効にすることも含まれます。

より良い実装やソリューションのために機能、関数、プロパティを廃止する必要がある場合、通常は現在の API をそのまま使用しますが、関連する API エンドポイントは「非推奨」とマークして、アプリケーション コードのエンドポイントから離れる必要があることを示します。

API の破壊的および追加的な変更

互換性を破る変更とは、API エンドポイントの既存のアーティファクトを削除または名前を変更することです。ケースログには以下が含まれます。

  • パラメータの名前または型を変更または削除する
  • 新しい必須パラメータの追加
  • ベース URL の変更
  • レスポンスで既存のプロパティを変更または削除する

一方、付加的な変更は、安定エンドポイントに行われる可能性があります。たとえば、次のような場合があります。

  • 新しい省略可能なパラメータ
  • レスポンスの新しいプロパティ(レスポンスでは不明なプロパティが無視されるため、REST API コミュニティでよくあることですが、これは壊れているとは見なされません。)

安定版の Looker API エンドポイントに新しいアーキテクチャや機能を導入するにあたって、大幅な変更が必要になる場合は、通常、その変更を新しいエンドポイントに追加し、新しい API バージョンにバンドルして、既存の API エンドポイントが変更されないようにします。

API エンドポイントのフラグ

ほとんどの API エンドポイントは安定版と見なされ、変更される可能性はありません。セキュリティの問題を解決するなどの極端な場合を除いて、Looker は安定したエンドポイントに互換性を破る変更をリリースすることはありません。

他の API エンドポイントは、ベータ版または非推奨として報告される可能性があります。

  • ベータ版のエンドポイントは現在も開発中であり、今後変更される可能性があります。互換性を破る変更から保護されることはありません。ベータ版エンドポイントを使用する際は、Looker API の変更がアプリや開発サイクルに特に悪影響を及ぼすかどうかを検討してください。ベータ版エンドポイントを使用する予定の場合は、Looker のリリースノートで変更点をご確認ください。
  • 非推奨エンドポイントは、今もサポートされているエンドポイントで、現時点でも使用できますが、今後のリリースで削除される予定です。非推奨エンドポイントを使用する古いコードを更新して、非推奨エンドポイントの使用を停止してください。Looker の今後のリリースでエンドポイントのサポートが解除されると、それを使用しているコードはすべて機能しなくなります。ほとんどの場合、非推奨のエンドポイントは機能改善によって置き換えられます。非推奨の関数やプロパティをアプリケーションで使用している場合は、コードをリファクタリングしてできるだけ早く置き換えることをおすすめします。

ベータ エンドポイントと非推奨エンドポイントは、API Explorer4.0 API リファレンスでそのようにマークされています。マークされていないエンドポイントは安定していると見なされます。

新しい API バージョンへの移行

クライアント SDK または API の URL を新しい API バージョンにアップグレードする場合は、アプリケーション コードを確認して、新しい API バージョンで変更された点に依存しているかどうかを確認する必要があります。次のことを必ず行ってください。

  1. アプリケーション コードを検索して、更新された関数、値、プロパティ名を探します。
  2. アプリケーション コードがタイプの変更(整数から文字列など)をサポートしていることを確認します。
  3. コードを監査します(以下のセクションを参照)。

コードの監査

一部の言語では、ビルド時に API の互換性を破る変更がコンパイル エラーとして検出されることがあります。

  • コンパイルされた厳密な型の言語でアプリを作成している場合は、既存のコードとは矛盾している、新しい API バージョンでパラメータやレスポンスのタイプに構造的な変更を加えると、コンパイル時のチェックとコンパイラのエラー メッセージによって容易に理解できるようになります。
  • アプリケーションが大まかに型付けされた動的言語(JavaScript、Ruby、Python など)で記述されている場合、新しい API バージョンで互換性を破る変更によって影響を受けるアプリケーションの部分を見つけることが困難になる場合があります。これらの種類の言語では、タイプの変更に関連する問題を見つけるためにランタイム単体テストが必要となる場合があります。

いずれの場合も、Looker API の呼び出し(疑似呼び出しではない)を含め、アプリケーション コードを実行する単体テストを用意することをおすすめします。