APIライフサイクルとは

APIは、ソフトウェア・アプリケーションが相互に通信してデータ、主要な機能、および機能を交換できるようにするルールまたはプロトコルのセットです。APIには、APIの作成と配布を中心としたAPIプロデューサーのライフサイクルと、コンシューマーの視点に立ったAPIの利用を中心としたAPIコンシューマーのライフサイクルがあります。この記事ではAPIプロデューサーのライフサイクルに焦点を当てます。

APIプロデューサーの普遍的なライフサイクルは存在しません。ソースごとにさまざまなバリエーションが考えられますが、ライフサイクルには通常、計画、設計、開発、テスト、デプロイ、監視、廃止の段階が含まれます。

API管理プラットフォームは、APIライフサイクル全体にわたる取り組みを組織し、IT環境全体でAPIストラテジー、 ガバナンス、ドキュメンテーション、ディレクトリーを集中管理するためによく使われます。多くのプラットフォームには、組織がAPIを最大限に活用できるよう、APIの検出と収益化のための高度な分析機能とツールが含まれています。

APIライフサイクル全体を検討して理解することで、開発チームは参考情報をより効率的に割り当て、現実的な配信スケジュールを作成し、プロセス全体を通じてすべての利害関係者に情報を提供し、APIがビジネス要件を確実に満たすようにすることができます。基本的に、適切に考え抜かれ実行されたライフサイクルは、高性能で安全なAPIとより強力なユーザー・エクスペリエンスを実現するのに役立ちます。

エンドツーエンドのAPIライフサイクル管理は、事前計画から始まり、多くの場合、廃止や置き換えによって終わりますが、必ずしもそうではありません。例として、顧客データをサポート・チケット、会計システム、プロジェクト管理プラットフォームなどのビジネス・ツールと同期するためのAPIの構築を決定するソフトウェア会社について考えてみましょう。

APIの構築は、いくつかの基本的な質問に答えることから始まります。なぜこのAPIは必要なのか、誰のためのものなのか、どのように使用されるのか、成功をどのように測定するのかといったものです。

APIプロジェクトの目標を具体的に示すことで、API設計に必要な主要な機能や特徴が明確になります。ソフトウェア開発の例では、APIの目標は、企業が使用している、または使用する予定のアプリケーションとプラットフォームの間で顧客データをシームレスに動きできるようにすることです。

この計画フェーズでは、組織は次のことを行います。

• APIの潜在的なビジネス上のメリットをレビューする
• このAPIがビジネス・ニーズにどのように所在地するかを説明する
• ネイティブ統合マーケットプレイスに必要なことを実行できる既存のAPIやその他の利用可能な製品がないことを確認する（基本的に、このAPIの構築が必要であることを確認）。
• どのアプリケーションとプラットフォームがAPIに依存するか、またAPIを既存のワークフローとどのように統合するかを明確に定義する。

次に、潜在的なユーザーとユースケースについて話し合う必要があります。これは単に社内使用のためのものか。このAPIを使用するのはどのチームで、何のために使用するのか。設計および開発段階で対処すべきセキュリティー上の懸念はあるか。そして最も重要なのは、API開発の各段階の責任者は誰か、ということです。

プロジェクト完了のタイムラインを設定することで、プロジェクトが予算内に収まることが保証されます。重要なのは、タイムラインが現実的かつ柔軟なものでなければならないことです。

チームは次のような質問に答えます。主要な機能のリリース日など、満たさなければならない特定の日付はあるか。このAPIをデプロイする前に、セキュリティチーム、法令遵守チーム、その他の利害関係者が承認する必要はあるか。

APIに関するドキュメンテーションやその他の情報はどこに保管され、開発者とユーザーの両方が同様に利用できるようになるのか。コードの変更はどこで追跡され、保管されるのか。

最初にこのような種類の質問に答えておくと、ライフサイクルの残りの期間に関する明確な計画を立てることができます。

計画段階では望ましい結果を記述しますが、設計段階では、チームがそこに到達するための方法を定義します。設計プロセス全体を通じて、API設計チームは、計画段階で詳述された要件を満たすために、APIをどのように構築する必要があるかを決定します。

チームは、APIが使用するプロトコルとアーキテクチャー・スタイルに関する設計上の決定を下す必要があります。この決定は、組織内の既存のAPIアーキテクチャーに基づくか、この新しいAPIの想定されるユースケースに基づく場合があります。

たとえば、一般的なAPIフレームワークとアーキテクチャーには、REST、GraphQL、gRPCなどがあります。それぞれに独自の長所と短所があります。

• REST：シンプルで直感的、どこにでもあるが、複雑なクエリには向かず、強力な型付けもできない。
  
  
• GraphQL：効率的で、強力な型付けと組み込みのドキュメンテーションを備えている。ただし、GraphQLは複雑な場合があり、RESTよりも多くのセットアップと特定の専門知識が必要になる。
  
  
• gRPC：高速、強力な型付け、自動コード生成、双方向ストリーミング。gRPCはマイクロサービス通信によく使用されます。しかし、新しいフレームワークとしては学習曲線が生じる可能性があり、またドキュメンテーション形式は人間が読めるものではなくバイナリーです。

APIを設計する際には、チームは適切な認証方式（OAuth 2.0など）や、APIをAPI Gatewayの背後に配置すべきかどうかについても決定します。

仕様文書には、APIの構造、動作、機能を標準化された方法で記述します。APIがどのように構築され、何ができるか、どのようにやり取りするかに関する情報を提供することで、信頼できる唯一の情報源を提供します。

最も一般的な標準仕様はOpenAPI仕様で、開発者はパス、メソッド、パラメーター、認証方法などを定義できます。OpenAPIはREST API専用に使用され、コード生成、編集、ドキュメンテーションの自動作成を提供するSwaggerと呼ばれるオープンソース・ツールセットをサポートしています。

GraphQLの場合、同等の仕様となるのがGraphQLスキーマです。GraphQLスキーマは、スキーマ定義言語（SDL）で記述された強力な型付け契約で、人間が読み取れる形式です。GraphQLエコシステムは、OpenAPIと同様の機能を提供する方法でこのスキーマを活用するいくつかの異なるツールを提供しています。たとえば、GraphiQLは、開発者がサンドボックスとして使用できるブラウザー内統合開発エコシステム（IDE）です。

gRPCでは、プロトコル・バッファー（またはprotobuf）は、仕様で最も一般的に使用されているファイル形式であるシリアル化形式およびインターフェース定義言語（IDL）です。Protobufはインタラクティブ・テストを提供しませんが、これを可能にするWeb UIがあります。

この段階では、開発者は前のステップで説明したAPI設計計画に従ってコーディングを開始します。バージョン管理システムは、開発プロセス全体を通してバージョンとコードの変更を追跡するために使用されます。

バージョン管理システムの業種・業務標準はGitです。これは、開発者のデバイスにローカルに保管されたコードの変更を追跡するオープンソース・ソフトウェアです。開発者はGitを使用してコードの作成、管理、変更の追跡を行いますが、そのためには、自分自身や他のユーザーがそのコードにアクセスできる場所が必要です。

GitHubは最も人気のあるGitホスティング・サービスであり、無料と有料の両方の層を提供しており、Gitコード・リポジトリーのストレージ、取得、コラボレーションを可能にします。GitLab、AWS CodeCommit、Microsoft Azure Repos など、Gitリポジトリをホストする代替手段があります。

APIテストは、API開発フェーズの間とその後の両方で実施されます。継続的なテストにより、脆弱性やニーズを明らかにし、定期的なアップデートを可能にすることで、開発を支援します。

単体テストでは、コードの小さな部分を分離し、個別にテストします。このソフトウェア会社のAPIの例では、チームがユーザーの情報を取得するリクエストに対するレスポンスをテストする必要があるとしましょう。GETコマンドは、顧客データベースにあるユーザーのID番号からユーザーの名前とEメール所在地を取得することを目的としています。単体テストでは、このGETリクエストが意図した情報を取得すること、および存在しないユーザーIDに対するリクエストが適切なエラー・メッセージを返すことを確認します。

統合テストは通常、単体テストの後に実行され、単体テストが見逃した問題を検知するために使用されます。Integration Testingは、複数のコンポーネントまたはサービスがAPIを介して意図したとおりに通信できることを確認するのに役立ちます。

例に戻ると、APIの主要な機能の1つが、新規顧客の追加などの特定のイベントの場合に、あるシステムから別のシステムにWebhook（通知）が送信されるとします。これが機能することを確認するために、新しい顧客の情報がCRMに追加されたときに、通知を受信し、期待されるアクションを実行する偽のサーバーを使用して統合テストを設定します。このプロセスはすべての統合で繰り返されます。

APIコントラクト・テストは、APIがユーザーが期待しているとおりの機能を発揮することを保証します。コントラクトは通常、OpenAPI仕様ファイルとして作成されます。これは、APIの機能と能力の要素を記載した、機械で読み取り可能な標準的なドキュメンテーションです。API仕様ファイルは通常、JSONまたはYAMLで書かれ、 APIエンドポイント、認証方法、許容されるリクエストおよびレスポンスの特定のフォーマット、メタデータ、インプット・パラメータなどの要素が含まれます。

APIの性能の評価には、一般的にその速度と効率の評価が含まれます。この段階では、テスト担当者はクエリの応答時間、エラー率、参考情報の使用量（CPUやメモリの使用量など）、レイテンシー、スループットを測定します。この段階でAPIの性能を理解することで、ユーザー/エクスペリエンスを遅らせる可能性のあるボトルネックや冗長性を明らかにすることができます。

APIは機密データの送信によく使用されるため、セキュリティー・テストは重要なコンポーネントです。APIセキュリティー・テストは基本的に、安全性と安定性を確保するために、さまざまな方法でAPIを破壊することを試みます。これらの試みには、データが事前に承認された形式でインプットされた場合にのみ受け入れられることを確認するためのインプット検証テストが含まれる場合があります。

インプット検証テストでは、さまざまなタイプの攻撃を探します。一般的な攻撃には、悪意のある攻撃者が悪意のあるコードをアプリケーションに挿入するSQLインジェクションが含まれます。SQLはデータベースと通信するために使用される言語であり、特定のユニバーサルSQLコマンドは、すべてのユーザーのリストなど、不正な応答をトリガーできる可能性があります。

その他のセキュリティー・テスト方法には、生体認証などの識別セキュリティー対策が適切に機能することを保証する認証テストや、ユーザーがアクセスを許可された主要な機能にのみアクセスできることを保証する承認テストなどがあります。

セキュリティー・テストは開発段階と開発後の両方で実施され、新しいAI主要な機能とオートメーションによって、これらのテストの強度と精度が向上しています。AIセキュリティー・テスト・ツールは、テストの自動生成、コードのバグのスキャン、性能データの分析をして問題の予測に役立て、異常な動作のフラグを立てるなど、さまざまなことを行えます。

ヘルスケアや金融サービスのような業種・業務では、ユーザーの安全性、セキュリティー、プライバシーを保護するための規制、法律、ガイドラインが存在します。例としては、HIPAA（米国のヘルス情報）、GDPR（欧州の個人情報）、CCPA（カリフォルニアの個人情報）などがあります。

コンプライアンス・テストとは、APIが適用法やガイドラインに準拠していることを確認するテストです。たとえば、GDPRでは「忘れられる権利」を付与しています。これは、ユーザーが不当な遅延なくデータの完全な削除を要求できることを意味します。GDPRに準拠したAPIのコンプライアンス・テストでは、このルールが遵守されていることを確認する必要があります。

デプロイメント段階はAPIの起動です。機能性、セキュリティー、コンプライアンスがテストされており、すぐに使用できます。デプロイメント段階では、APIはテスト環境から実際の運用環境に動きします。APIのデプロイには、いくつかの手順が必要です。

デプロイメントの前に、チームは別のレビューを行い、サポート・インフラストラクチャー、APIドキュメンテーション、ユーザー・サポート、配布および通信ストラテジー、監視プロトコルがすべて完了し、すぐに使用できるようにする必要があります。このチェックリストには、サーバーの拡張、Alerts and Notificationの構成、FAQページの作成、顧客へのお知らせ（または社内での発表）などが含まれる場合があります。

CI/CD（継続的統合／継続的デプロイメントの略）は、ソフトウェア開発、テスト、デリバリーのサイクルを自動化し、合理化する一連のプラクティスです。これはDevOps手法における基本的な実践方法です。ソフトウェアアプリケーションと同様に、APIも一般的にCI/CDパイプラインに組み込まれ、APIのデプロイメント、テスト、更新を効率化および自動化します。

API Gatewayとは、クライアントが様々なバックエンド・サービス、あるいは複数のバックエンド・サービス・インスタンスにアクセスするための単一のエントリポイントを提供するソフトウェア層です。API Gatewayにはいくつかの利点があります。

• シンプルさ：クライアントは、多数のサービスURLではなく単一のサービスURLのみを追跡する必要があります。
  
  
• 負荷分散：組織は、単一サービスのトラフィックを複数のインスタンスに分散して、負荷を分散し、性能のボトルネックを回避できます。
  
  
• セキュリティーとガバナンス：ゲートウェイを使用すると、標準化されたセキュリティーおよびガバナンスのプロトコルを多数のAPIに適用できます。
  
  
• キャッシュ： ゲートウェイは、複数のサービス間で頻繁にアクセスされるデータを保管することで、キャッシュに役立ちます。これにより、応答が加速し、性能が向上します。

組織は、APIを完全公開する前にテストするために、特定のユーザー向けにベータ版リリースを発行することがよくあります。これにより、組織はバグを発見して修正し、フィードバックを求め、性能を測定し、より安全でより制御された環境でAPIを推進することができます。

チェックリストとベータ版のリリースが完了したら、「スイッチを入れて」APIを完全にデプロイします。このプロセスには、内部または外部の顧客にAPIについてさらに情報を提供し、その使用を促すための配布ストラテジーのInitiate® が含まれる場合があります。配布プロセスには、ユーザーガイドやその他のパブリック・アウトリーチの公開、WebサイトまたはAPIディレクトリーの更新、プライベート認証を必要とするのではなく即時アクセスを可能にする設定の調整も含まれる場合があります。

APIのライフサイクル全体を理解して計画することの主要なメリットの1つは、最初から監視、オブザーバビリティー、保守に重点を置くことができることです。ローンチ時点で仕事は完了したわけではなく、まだやるべきことが残っています。APIモニタリングは継続的なプロセスであり、APIが実世界でどのように動作するかをリアルタイムで確認するように設計されています。

監視の主要なメトリクスには、応答時間、つまりAPIがリクエストに応答するのにかかる時間やエラー率、または失敗した要求の割合スループットとトラフィック、またはAPIが処理できるリクエストの数、およびサーバーの負荷と正常性を測定するインフラストラクチャー分析が含まれます。

保守要素は、監視ツールによって収集されたデータに応答して提供されます。保守は、バグ修正、性能の最適化、さらには新しい主要な機能や性能の追加などの形で実施されます。

CRMの例では、顧客データがあるプラットフォームから別のプラットフォームに送信されるときに、レイテンシーが大きいことを監視ツールが検知できる場合があります。保守フェーズでは、コードの冗長性を減らすか、キャッシュ設定を微調整するか、サービスを提供する顧客の近くにサーバーを再配置することで、この問題に所在地できます。

APIのライフサイクルの終わりは、他の段階と同じくらい重要で、動的で、情報に富んでいます。

バージョン管理とは、APIの有効な期間にわたって更新を行うことでAPIの有効性を維持する長期的なプロセスです。バージョン管理の鍵は、確立されたユーザー向けに既存の機能を壊すことなく、変更や改善を提供することです。

単純な修正プログラムなどの場合、これらの小さな変更は「互換性がない」と見なされるため、通常、新しいAPIバージョンを適用せずに更新が発行されます。ただし、新しいバージョンが、置き換えようとするバージョンと下位互換性がないような「破壊的」な変更の場合は、変更を新しいバージョンとして導入することをお勧めします。

早期かつ頻繁なコミュニケーションは、バージョン管理の鍵です。一般的な方法は、並行バージョンをサポートすることです。古いバージョンは新しいバージョンと並んでアクティブで機能し続け、開発者はユーザーに変更内容を伝えて、新しいバージョンへの移行を促します。すべてのユーザーまたは十分な数のユーザーが移行したら、古いバージョンを非アクティブ化できます。

廃止とは、APIを完全に削除して無効化することです。すべてのAPIが廃止されるわけではありませんが、最終的にAPIが置き換えられることはよくあります。APIが廃止される理由はいくつかあります。

• 新しいバージョンが優れた性能を提供する
• コンプライアンスやセキュリティーのニーズに適切に対応できていない
• 組織内のビジネスまたは財務上の変化
• 新しいソフトウェアとの非互換性

廃止後、APIは機能しなくなります。ただし、この移行を容易にするための段階がいくつかあります。

APIの廃止については議論が必要です。APIを廃止する必要があるのか、また、その理由は？代替手段は何か、差し迫った廃止を認識する必要があるのは誰か。

通常、組織はAPIの廃止期限を発表します。この発表には、この変更が行われる理由、いつ発生するか、ユーザーがどのようなアクションを取る必要があるか（存在する場合）など、APIのユーザーに必要な情報がすべて含まれています。

その後、APIは正式に廃止されます。この時点ではAPIは引き続き動作しますが、新しいアップデートや主要な機能を受け取ることはできません。非推奨期間は、ユーザーに必要な調整を行うための時間とアウェアネスを与えるように設計されています。

「サービス終了日」とは、パブリックAPIが完全にオフになることです。その時点でリクエストは応答されなくなり、APIにアクセスしようとするクライアントにエラー・メッセージが表示されます。ドキュメンテーションを更新してこの変更を反映させ、APIが使用していたサーバー・スペースやその他のインフラストラクチャーを解放することをお勧めします。

廃止したAPIの事後分析は有益な作業になる可能性があります。チームは、APIライフサイクル全体にわたって学んだ教訓と、それらを将来のプロジェクトにどのように適用するかについて話し合うことができます。