現在、ウェブベースのサービスでは、地図、天気情報、画像サービスから、ゲーム、オークションまで、多種多様な機能を提供しています。サービス プロバイダには、サービスを実装、デプロイ、管理する方法が多数用意されています。たとえば、Java や .NET で開発されたサービスもあれば、Node.js を使用するサービスもあります。
バックエンドの実装は、1 つのサービス プロバイダで変更することもできます。あるサービス プロバイダが 1 つのアーキテクチャを使用して実装したレガシー サービスがあり、新しいサービスがまったく異なるアーキテクチャを使用して実装されている場合もあります。
実装にかかわらず、ウェブベースのサービスはすべて、アプリ デベロッパーがサービスを利用できるようにする必要があります。多くの場合、これらのサービスは一連の HTTP エンドポイントとして公開されます。サービスによっては、エンドポイントからクライアント アプリに XML 形式または JSON 形式のデータが返される場合もあります。
Google Cloud Platform サービスについて
Google Cloud Platform(GCP)でサービスを開発する場合、Cloud Functions、Cloud Run、App Engine スタンダード環境など、さまざまな方法でサービスを実装できます。GCP の柔軟性により、サービス要件に適したバックエンド アーキテクチャを選択できます。
アプリ デベロッパーはバックエンド サービスの顧客です。アプリ デベロッパーがサービスを利用して、モバイル デバイスやタブレット用のアプリ、ブラウザで実行されているアプリ、サービス リクエストを行うことができる任意のタイプのアプリを実装します。
サービスをウェブで公開することが困難な場合があります。成功させるには、サービス プロバイダは次のことを行う必要があります。
- サービスへのアクセスを認証する
- クライアントとサービスの間のデータ転送を保護する
- 悪意のある攻撃からサービスを保護する
- 使用量の増減に応じてサービスをスケーリングする
- バックエンド オペレーション チームに、サービスの使用状況のモニタリングと追跡のための手段を提供する
- 使用状況を追跡して正確なお支払い情報を提供する
また、サービスで異なるインターフェースやプロトコルを使用する場合、アプリ デベロッパーにとってこれらのサービスへのアクセスは困難になる可能性があります。デベロッパーは、各サービスのインターフェースを学習して理解するだけでなく、さまざまなサービスの変更をモニタリングし、必要に応じてアプリを更新して再デプロイする必要があります。
API ゲートウェイ
API Gateway を使用すると、サービスの実装に関係なく、すべてのサービスで一貫している明確に定義された REST API を介してサービスに安全にアクセスできます。一貫性のある API とは、次のような API のことです。
- アプリ デベロッパーがサービスをより簡単に使用できる
- パブリック API に影響を与えることなく、バックエンド サービスの実装を変更できる
- Google Cloud Platform(GCP)に組み込まれているスケーリング、モニタリング、セキュリティ機能を活用できる
次の図は、アプリ デベロッパーが API Gateway を介してバックエンド サービスにリクエストを送信する方法を示しています。
アプリ デベロッパーは API Gateway を使用し、REST API を使用してアプリを実装します。すべての API は API Gateway でホストされているため、アプリ デベロッパーは、すべてのバックエンド サービス間で一貫したインターフェースを使用できます。
API Gateway に API をデプロイすることにより、API を変更せずに、バックエンド サービスを更新したり、アーキテクチャ間でサービスを移動したりできます。サービスに対する API の一貫性が維持されている限り、基盤となる変更はバックエンドで行われるため、アプリ デベロッパーはデプロイしたアプリを変更する必要がありません。
API Gateway は、API の作成、共有、維持、保護に役立つ、ホスティング、ロギング、モニタリングなどの機能を備えた分散 API 管理システムです。API Gateway は GCP とネイティブに統合されており、同時 API 呼び出しの処理に関連するすべてのタスク(トラフィック管理、認可、モニタリングなど)を処理します。
API とは
API とは、あるアプリケーションが別のアプリケーションの機能やデータを簡単に「利用」できるようにするインターフェースです。持続性のあるシンプルで文書で十分に裏付けられたエントリ ポイントを定義することで、他のデベロッパーによって構築されたアプリケーション ロジックへのアクセスやそれらの再利用を簡単にします。
たとえば、次の表は、書籍に関する情報を返すことができる REST API の例を示しています。
プロパティ | 値 | 説明 |
---|---|---|
URL | https://www.mybooksapi.com/books/info | 国際標準書籍番号(DRM)に基づいて、書籍のタイトル、著者、出版日を返します。 |
HTTP 動詞 | GET | API に対して GET リクエストを行います。 |
Query param | isbn
|
書籍の DRM 番号、つまり書籍の ID を渡します。 |
Response data | { "title" : "book_title", "author" : "author_name", "published" : "publish_date" } |
書籍の詳細を含む JSON オブジェクト。 |
レスポンス コード | 200 | リクエストが正常に処理されました。 |
この情報を使用して、書籍に関する情報を取得するには、この API で次の cURL リクエストを行います。
curl -X GET https://www.mybooksapi.com/books/info?isbn=0385504217
このサービスには、データ形式や HTTP レスポンス コードの説明など、明確に定義された API があるため、アプリ デベロッパーはバックエンド サービスの基盤となる実装について何も把握する必要がありません。
API を使用するアプリケーションには変更が多発するため、API には API プロバイダと API 利用者の間の契約も含まれています。この契約では、API が時間の経過とともに予測可能な方法で変更されることが保証されています。たとえば、Book API を更新して、title
や author
などのクエリ パラメータを追加することもできます。また、レスポンスの JSON を変更して書籍に関する追加情報を追加することもできます。
API の定義
API Gateway にデプロイされた API を OpenAPI 2.0 仕様として定義します。API 定義の主なコンポーネントは次のとおりです。
- バックエンド サービスの URL(エントリ ポイント)
- API へのリクエストに渡されるデータのデータ形式
- API からのレスポンスでサービスから返されるデータのデータ形式
- サービスへのアクセスを制御するために使用される認証メカニズム
API を定義したら、gcloud コマンドライン インターフェースを使用して GCP の API 構成にアップロードします。
API Gateway への API 構成のデプロイ
API を作成するには、API Gateway に API 構成をデプロイします。gcloud
コマンドを使用して API 構成をデプロイします。
API 構成がデプロイされると、クライアントは API に対して REST 呼び出しを行えます。
API の管理
デプロイして実行したら、使用状況の指標やログなどの API アクティビティをモニタリングできます。クライアントが API に対してリクエストを行うと、API Gateway はリクエストとレスポンスに関する情報をログに記録します。API Gateway はレイテンシ、トラフィック、エラーも追跡します。
時間の経過とともに、デプロイされた API を更新して、新機能の追加、パフォーマンスの改善、API の問題を解決することが必要になる場合があります。デプロイされた API を更新するには、API 定義用の OpenAPI 仕様を更新してから、API をアップロードして再デプロイします。
API アクセスの制御
API Gateway を使用すると、クライアントが API にアクセスする前に認証を要求するように API を構成できます。現在 API Gateway では、以下を含め Cloud Endpoints で使用されているものと同じ認証メカニズムと構文がサポートされています。
また、Google Cloud Platform Console を使用して他のデベロッパーと API を共有すると、共有相手のデベロッパーがその API を有効にして、API を呼び出すための API キーを生成できます。
API はユーザーの ID を確認する認証メカニズムを定義するだけでなく、API を使用して認証されたユーザーが実行できる操作を決定する必要もあります。詳細については、GCP Auth ガイドをご覧ください。