APIとエンドポイントは、フロントエンド開発者とバックエンド開発者の間で欠かせない役割を果たしてきました。有用で持続可能なアプリケーションやサービスを開発する上で、APIは非常に大事な要素です。
APIは、顧客の問題解決を支え、様々なソフトウェア間のデータ伝送を容易にします。ありとあらゆるウェブベースの製品に独自のAPIがあり、それを使うことでサービスとの統合ややりとりが可能になります。
競合他社に遅れを取らず、プラットフォーム間でシームレスな体験をユーザーに提供するためには、APIについて理解を深め使いこなす必要があります。
このページでは、APIエンドポイントとは何か、公開されているAPIをどのように利用できるか、APIエンドポイントをセキュアに監視する方法について、用語を噛み砕きながらご説明します。
APIエンドポイントとは
「API」とは「Application Programming Interface」の略です。基本的には、アプリケーションが他のアプリケーションとデータを共有するための一連のルールだとお考えください。簡単に言えば、APIはあなたのアプリケーションとサードパーティアプリケーションの間で「橋渡し」の役割を担います。
APIの「エンドポイント」とはデジタル空間に公開されている一種のロケーションです。この場所を通じてAPIによるリクエストの受け取りとレスポンスの送信が行われます。各エンドポイントは、実際には、APIサーバー上のリソースの場所を指定するURL（Uniform Resource Locator）のかたちを取ります。
APIの目的と使い方を理解するために、まずAPIの仕組みを理解しましょう。
APIの仕組み
2つのソフトウェアアプリケーションがインターネット上で通信するには、一方のアプリケーション（クライアントと呼ばれる）がもう一方のアプリケーションのAPIエンドポイント（サーバーと呼ばれる）にリクエストを送信します。APIの機能に応じて、クライアントはデータベースからリソースを要求したり、サーバーにその環境で何らかのアクションを実行し、結果を返すように要求したりします。
クライアントから結果を受け取ると、API（またはサーバー）は要求された操作を実行し、操作の結果をレスポンスの形でクライアントに送り返します。このレスポンスには、クライアントが要求したリソースを含めることもできます。
APIには、REST、SOAP、GraphQLなどさまざまなタイプがあります。これらはすべて異なる動作をしますが、その目的は同じで、ウェブベースのエンティティ間のコミュニケーションを促進することです。以後の説明では、世界的に広く活用されているAPIであるREST APIを主に対象にしたいと思います。
APIとエンドポイントの違い
次に、こんな疑問に迫ります。APIとエンドポイントの違いとは。
APIとは、2つのアプリケーション間のインタラクションを容易にするためのプロトコルでありツールです。エンドポイントとは、実際にそのやり取りが行われるAPI上の場所（特定のポイント）のことです。エンドポイントは、アプリケーションがアクセスできるAPI上のURI（Uniform Resource Identifiers）になります。
すべてのAPIにはエンドポイントがあります。エンドポイントがなければ、APIとやりとりすることができません。
エンドポイントがAPIとどのように連携するのか
APIとエンドポイントについて理解するために、小さな例を取り上げてみましょう。
Cat Facts APIについて考えてみます。このAPIは猫についての情報をランダムに取り出して返します。とはいえ、情報の種類などについて指定できるように、複数のエンドポイントが用意されています。具体的には以下の3つです。
/fact：猫についての情報を1つランダムに返す/facts：猫についての情報を複数ランダムに返す/breeds：猫の種類を返す
このAPIにリクエストして猫についての情報を取得するには、APIのベースURL（https://catfact.ninja/）に該当するエンドポイント（/fact）を追加します。これにより、https://catfact.ninja/factのようなエンドポイントURLが得られます。
上記のURLにGETリクエストを送ると、以下のような結果が返されます。
{
"fact": "Spanish-Jewish folklore recounts that Adamu2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the childu2019s breath.",
"length": 245
}
もちろん、/breedsのような別のエンドポイントにアクセスすると、同じデータは取得できません。このように、エンドポイントはAPIによって提供されるリソースと対話したり、それを整理したりするのに効果を発揮します。
なぜAPIエンドポイントが重要なのか
データ転送とリソースの共有は、インターネットの基盤です。日々、数多くのプロセスやアプリケーションがグローバルネットワークに追加され、モノを共有することでネットワークに付加価値を与えています。
APIがなければ、このようなことはできないでしょう。APIはウェブベースのアプリケーション間のコミュニケーションと相互作用に欠かせません。
APIエンドポイントは、API内のリソースの正確な位置を特定する役割を果たします。APIエンドポイントは、API開発者が利用可能なリソースを整理し、利用者のアクセスを制御するのにも役立ちます。したがって、APIを使用するアプリケーションのパフォーマンスと生産性は、APIエンドポイントの設計とパフォーマンスに直接依存します。
既存のAPIエンドポイントとの連携
ほとんどの場合、構築済みのAPIを利用することになります。それを効率的に行うには、エンドポイントの探し方を理解し、業界で使用されている様々なバージョン管理ルールを理解する必要があります。このセクションでは、それらについて詳しくご説明します。
APIエンドポイントの検索
APIドキュメントにアクセスさえすれば、APIエンドポイントを見つけるのは簡単です。ドキュメントには通常、エンドポイントが列挙されており、それぞれの横に短い説明が添えられていることもあります。時には（Swaggerなど）、ドキュメントがそれ以上に作り込まれており、ドキュメントのページからすぐにエンドポイントをテストできることもあります。
いずれにせよ、使い始める前に各エンドポイントの目的を理解することに時間を割くのが得策です。そうすることで、ほとんどのエラーを回避し、効率を高めることができます。
APIエンドポイントのバージョン管理
他のほとんどのソフトウェア成果物と同様に、APIにもバージョン管理の概念があります。バージョン管理により、開発プロセスを通じたAPI発展の追跡、分析が捗ります。古いバージョンにアクセスできることで、アップデートで不具合が発生した際には、以前の安定したバージョンにロールバックできます。APIエンドポイントのバージョン管理は一般的に以下の方法で行います。
URIパス
APIエンドポイントのバージョン管理として最も一般的なのが、URIパスにバージョン番号を追加することです。以下のようになります。
http://example.com/api/1/resourcenameこれは、APIエンドポイントを「グローバルに」バージョン管理する方法とみなすことができます。APIにサブドメインを使用する場合、例えば以下のようになります。
http://api.example.com/resourcenameまた、以下のようにサブドメインにバージョンを示す値を記述することもできます。
http://api-v2.example.com/resourcenameご覧のように、この方法ではAPIのURIルートが変更されるため、各バージョンが独立したリソースとして動作します。つまり、必要に応じて2つのバージョンのAPIに同時にアクセスすることができ、さらに素早くアクセスするためにそれらを独立してキャッシュすることも可能です。
URIパスにバージョン番号を含める場合（サブドメインには含めない）、詳しい情報を示すためにおすすめの書式が以下の通りです。
MAJOR.MINOR.PATCH例えば、上記の例の内部APIはこのようにバージョン分けされています。
http://example.com/api/1.2.3/resourcenameそれぞれの用語と用途については以下の通りです。
- MAJOR（メジャー）：互換性のない、あるいはAPIの根幹に影響を及ぼすような変更を加える場合
- MINOR（マイナー）：後方互換性のある機能を追加する場合
- PATCH（パッチ）：後方互換性のあるバグの修正を行う場合
MAJORは、公開APIで使用されるバージョンです。この番号は通常、APIに大きな変更が加えられたとき、あるいは別のバージョンのAPIを破壊するような変更が加えられたときに更新されます。内部的には、新しいAPIインスタンスまたはリソースが作成されたことを示します。
MINORバージョンとPATCHバージョンは、後方互換性のある更新や修正を示すために使用されます。これらは通常、新しい機能が導入された場合や、同じAPIリソースにマイナーな変更が加えられた場合に更新されます。PATCH番号は、特にバグの修正や問題解決に関連したものになります。
- メリット
- 複数のバージョンへの同時アクセスが可能
- URLの命名はシンプルで標準的な規約に従っているため、APIエンドポイントへのアクセスが容易
- 制限事項
- 変更を加える場合、このアプローチは新しいAPIリソースの開発につながる（コードに大きな負担をかけることになる）
クエリパラメータ
REST APIのバージョン管理を行うもう一つの方法が、URLのクエリパラメータにバージョン番号を入れることです。これにより、サーバー環境が必要なバージョン番号に他のクエリーパラメータと同様にアクセスし、それを使用してアプリケーションの制御フローをリダイレクトできます。既存のAPIリソースがバージョン番号を読み取り、必要に応じて対応できるため、新しいAPIリソースを作成する必要性は生じません。
クエリパラメータを使用してバージョン管理を行うと、先ほどの例のURLは次のようになります。
http://example.com/api/resourcename?version=1- メリット
- コードでの実装が非常に簡単
- すぐに最新バージョンにデフォルトの設定を行える
- 制限事項
- パラメータは、URIパスのバージョン管理よりも、リクエストを正しいバージョンにルーティングする際には困難になり得る
カスタムヘッダー
バージョン番号を属性として持つカスタムヘッダーを提供することで、REST APIのバージョン管理を行うこともできます。この方法と前述の2つの方法の最も大きな違いとして、この方法ではエンドポイントのURLをバージョン情報でごちゃごちゃにするのを回避できます。
先ほどの例をこの方法でバージョン管理すると、このようになります。
curl -H "Accepts-version: 2.0"
http://example.com/api/resourcename- メリット
- URLがバージョン情報でごちゃごちゃしない
- クライアントからすれば、APIエンドポイントURLをハードコーディングにより記述し、リクエストを素早く送信しながらヘッダーを介してバージョンを選択できる
- 制限事項
- リクエストを行うたびに、カスタムヘッダーを手動で設定する必要がある
コンテンツネゴシエーション
コンテントネゴシエーションによって、API開発者はAPI全体ではなくリソースの特定の表現を対象にバージョン管理を行えるようになります。これにより、バージョン管理の細かな制御が可能です。前の例と同じように、この選択肢でもAPI URLをきれいに保つことができます。
先ほどの例を使って、コンテンツネゴシエーションによってバージョン管理を行うと以下のようになります。
curl -H "Accept: application/vnd.kb.api+json; version=2"
http://example.com/api/resourcenameしかし、この方法でバージョン管理するエンドポイントには、URIの方法よりもアクセスしにくいという難点があります。さらに、メディアタイプを持つHTTPヘッダーの使用は、ブラウザでのAPIのテストを困難にします。また、コンテンツヘッダーがオプション（指定が任意）の場合、クライアントがデフォルトでどのバージョンを受け取るのか混乱が生じる可能性があります。
例えば、APIのv2をリリースし、古いバージョンのv1を非推奨にしたとします。もしクライアントがリクエストでバージョンを指定しなければ、v2リソースを受け取ることになり、未確認の互換性の問題で機能が壊れてしまうかもしれません。これが、通常APIのバージョン管理の手段としてコンテンツネゴシエーションが推奨されない理由です。
- メリット
- 必要に応じて単一のリソースを対象にしてバージョン管理ができる
- コードのフットプリントが小さくなる
- ルーティングルール（URL）を変更する必要がない
- 制限事項
- メディアタイプを持つHTTPヘッダーに関連して、ブラウザでエンドポイントをテストしたり探索したりすることが難しくなる
- コンテンツヘッダーがないと、クライアントの機能が壊れる可能性がある
APIエンドポイントの例
APIとエンドポイントをよりよく理解するために、Twitter APIを使った例をご紹介します。このAPIを通じて、プラットフォームのツイート、ダイレクトメッセージ、ユーザーなどに関するデータが公開されています。データに対して様々な操作を実行できるよう複数のエンドポイントがあります。
例えば、ツイート検索のエンドポイント（https://api.twitter.com/2/tweets/{id}）を使用すると、一意の識別子を使って特定のツイートの内容を取得することができます。また、Twitter APIを使って、公開されているツイートをリアルタイムでウェブアプリケーションにストリーミングし、ユーザーに特定のトピックに関する情報を提供することもできます。
Twitter APIには、これを可能にするフィルタリングストリームエンドポイントがあります(https://api.twitter.com/2/tweets/search/stream)。また、Twitter APIには他のエンドポイントの拡張インデックスも用意されています。
APIエンドポイントはどのように保護されているのか
APIエンドポイントがどのようなもので、どのように機能するかを理解したところで、今度はこれのセキュリティを扱います。適切なセキュリティ強化策がなければ、APIエンドポイントはアプリの大きな弱点となり、データやリソースの侵害につながる可能性があります。
APIエンドポイントへのアクセスを安全にするための基本的な策をご紹介します。
一方向パスワードハッシュ
ウェブリソースを構築する際、エンティティを認証する方法としてパスワードに出くわすものです。パスワードはユーザーのアプリケーションデータを保護するのに役立ちますが、真に効果的な認証媒体とするためには、パスワードの保存方法についても保護する必要があります。
パスワードは決してプレーンテキストとして保存すべきではありません。セキュリティの侵害が発生し、ユーザー名とパスワードの文字列ペアのテーブルにアクセスされると、すべてのユーザーアカウントが危険にさらされます。
これを防ぐ一つの方法が、パスワードを暗号化してから保存することです。暗号化には対称型と非対称型の2つの方法があります。
対称暗号化では、コンテンツのロックと解除に同じ暗号化キーを使うことができます。しかし、手の込んだハッキングではこれを簡単に破ることができるため、パスワードにはお勧めできません。
推奨されるパスワードの保存方法は、一方向暗号化または「非対称」と呼ばれる暗号化です。単一の暗号化キーを使用する代わりに、数学的関数を使用しデータをスクランブル（難読化のための処理）します。
スクランブルしたものがデータベースに保存されるため、サーバー管理者を含め、誰もパスワードを解読して閲覧することはできません。ユーザーを認証するために、入力されたパスワードは同じ計算にかけられ、その結果が比較され、入力されたパスワードが正しいかどうかチェックします。
HTTPS
APIエンドポイントで、ユーザーとサービスのやり取りができるように設計されているとします。そんな時には、HTTPS（または他の同様のセキュリティプロトコル）を実装しないと、消費者を重大なリスクにさらす可能性があります。
API接続は通常、パスワード、秘密鍵、支払い情報などの機密データを交換します。このようなデータは、マシン・イン・ザ・ミドル攻撃やパケット・スニッフィングによって簡単に盗まれる可能性があります。
このため、可能であれば常にHTTPSを選択する必要があります。いまだにHTTPプロトコルを使用しているアプリは、HTTPSへの移行を今すぐ検討すべきです。どんなに些細な接続であっても、漏えいにつながる可能性があります。
また、APIのセキュリティをさらに強化するために、TLSまたはSSL証明書を取得することもお忘れなく。
レート制限
ほとんどの場合、APIを1分間に使用できる回数に制限を設けるのが得策です。リソースの不正使用を制御し、消費者のトラフィックに基づいた価格モデルを管理することができます。
しかし、レート制限を導入する主な理由は、自動化によるリソースの過剰使用を避けるためです。これは通常、毎秒数百または数千の同時リクエストを送信することのできるボットへの対策となります。レート制限は、このようなボットによるDDoS攻撃をブロックする上で効果的です。
ほとんどのウェブ開発フレームワークに、セットアップが簡単な、すぐに使えるレート制限ミドルウェアが提供されています。フレームワークにミドルウェアがない場合でも、サードパーティのライブラリ経由で入手し、短時間で設定することができます。
ボットに注意することとは別に、許容されるリクエスト数やデータ取得数を合理的な数に制限することもベストプラクティスです。そうすることで、無限ループのようなエラーによって引き起こされる、意図しないリソースの使いすぎを防ぐことができます。また、ユーザーに均一な可用性を確保するのにも役立ちます。あるユーザーの使用量が急増した際に他のユーザーへの影響を防ぐことができます。
APIの認証
公衆向けのAPIを構築する場合は常に、サービスの誤用や悪用を防ぐための認証を実装する必要があります。優れた選択肢の一つがOAuth2システムです。
OAuth2システムでは、アカウントをリソースに分割し、認証トークン保持者に制御の行き届いたアクセスを提供することができます。このトークンでは、例えば24時間などの期限を設定可能です。たとえトークンが流出したとしても、使用期限が限定されているため、被害の可能性を軽減することができます。
APIセキュリティの要点として、リクエストの認証にAPIキーを使用することができます。APIキーを設定することで、APIへの呼び出し速度を制限し、DoS攻撃の可能性を減らすことが可能です。有料のAPIサービスを提供している場合、APIキーを使用して、各ユーザーが購入したプランに基づいたアクセスを管理することができます。
また、社内の従業員のエンドポイントに多要素認証、ウイルス対策ソフトウェア、アプリの自動アップデートを導入することもおすすめします。このような簡単な対策で、提供するサービスの品質を確保することが可能です。
入力のバリデーション
どのようなソフトウェアアプリケーションを構築する場合でも、バリデーションの実装が重要です。これは当然の要件として認識されるべきものですが、実際には驚くほど多くのAPIでこれが適切に実装されていません。入力バリデーションとは、入力されたデータが正しい形式であることをチェックするだけでなく、予期せぬ事態を未然に防ぐものです。
単純かつ厄介な例の1つがSQLインジェクションです。これを対策しないと、間違ったクエリが実行された場合、データベース全体が消し飛ぶ可能性すらあります。入力データが適切な形式であるかどうかを検証し、問題となる可能性のある情報を取り除くようにしましょう。
もう一つ気をつけなければならないのが、リクエストのサイズです。POSTリクエストの場合、極端に大きな入力を受け入れて解析しようとすると、APIに問題が生じる可能性があります。まず最初にPOSTリクエストのサイズを検証し、必要であればエラーコードとメッセージをクライアントに返すことに常に注力すべきです。
IPアドレスのフィルタリング
B2Bサービスを提供し、クライアントが設定されたロケーションからAPIを使用する場合には、ロケーションに基づいてAPIにアクセスするIPアドレスを制限し、システムにセキュリティの層を追加できます。
新しいロケーションや顧客については、そのデータを「許可対象」として一覧に追加する必要があります。これは、顧客のオンボーディングプロセスにおける一種の手間となる可能性がありますが、セキュリティを強化し、ひいては顧客のエクスペリエンスを高めることに大きく貢献します。
さらにセキュリティリスクを最小にとどめるために、クライアントの権限とアクセスを標準的な操作に必要な最小限に制限することも重要です。同様にHTTPアクセスも制限し、誤った設定によりクライアントがAPIの仕様とアクセスコード以上のものを受け取らないようにする必要もあります。APIがそのようなリクエストを405レスポンスコードで拒否するように設定しましょう。
興味深いことに、世界中のサイバー攻撃の大部分が限られた国から発生しています。もしそこにクライアントがいないのであれば、特定の場所からのリソースへのアクセスをブロックすることもできます。
攻撃を検知したら、攻撃者の地域からのGET/POSTリクエストをブロックすることから始めましょう。クライアントの所在地に基づいてHTTPリクエストを制限するのは、発生したサイバー攻撃に対抗する素早く効果的な選択肢です。
XDR（Extended Detection and Response）
ほとんどの組織では、ファイアウォールや侵入防御・検知技術といった従来型のセキュリティ強化策が導入されています。これらはあらゆるセキュリティシステムの基礎として重要ですが、API向けに明確に設計されたものではありません。
XDRと呼ばれる最新のテクノロジーは、APIエンドポイントを含むIT環境全体の守りを固めるものです。XDRを利用することで、不審な行動に関するアラートがリアルタイムでセキュリティチームに共有され、この情報をもとに攻撃に関する調査を素早く行うことができます。
XDTはより具体的には、以下の側面からAPIエンドポイントのセキュリティを強化します。
- HTTPSモニタリング：XDRは、エンドポイントのセキュリティ証明書を管理し、HTTP通信も検査できます。異常を検出すると接続をすぐさま切断するか、その他の定義したアクションを自動で行います。
- APIコールのモニタリング：XDRは、クライアントによるAPIコールの数を追跡し、設定されたレート制限内であっても不審な傾向を検出した場合は、セキュリティチームに通知します。
- JSONウェブトークン（JWT）：JWTは、ネットワーク上で通信する際に、ユーザーのIDを安全に表現するために使用されます。XDRにより、認証情報を送信することなく、ネットワーク上のJWTを介してユーザーを識別することができます。これにより、APIトラフィック内のユーザーアカウントを特定し、その挙動に異常がないか分析可能です。
- IPアドレスフィルタリング：XDRは、脅威インテリジェンスデータベースと連動するため、受信リクエストについての正当なIPアドレスまたは発信元をチェックすることができます。
- 入力内容の検証：サービス内に適切な入力サニタイズ策を導入していない場合でも、XDRソリューションはSQLやその他のデータベースセンシティブなクエリを自動で解析してインジェクション攻撃を検出し、その場で阻止してセキュリティチームに通知することができます。
メンテナンス作業
APIのセキュリティの質を高めるためにメンテナンス作業が欠かせません。例えば以下の通りです。
- データのクリーンアップ：サービスから冗長なユーザーと従業員のデータを削除する必要があります。定期的なデータのクリーンアップは、偶発的なデータの損失や破損の可能性を減らすのに有効です。
- 定期的なアップデート：技術スタックとサービス認定を定期的に更新することをお忘れなく。エンドポイントサービスには定期的にパッチを適用し、ライセンシングには最新の規制基準やコンプライアンス基準を反映させるようにしましょう。
- セキュリティ強化策の見直し：セキュリティ強化策と復旧計画を常に最新の状態に保つことも重要です。ネットワークインフラに対する変更や追加の内容を頻繁に反映する必要があります。新しいモバイル、IoT、その他のオンプレミスリソースを定期的に追加する場合は、この意識がさらに重要になります。
APIエンドポイントのモニタリング
APIエンドポイントの構築方法、利用方法、セキュアなAPIエンドポイントについて理解したところで、続いてはAPIエンドポイントのモニタリングを考えてみましょう。モニタリングは、技術的な製品の成長を分析し改善につなげるために、ソフトウェアエンジニアリングにおいて欠かせない概念です。
要点とベストプラクティス
APIエンドポイントでいえば、モニタリングは、パフォーマンスの改善と信頼性の確保、そしてエンドポイントの保護や最適化につながります。この次のセクションでは、API エンドポイントのモニタリングの際に従うべきベストプラクティスをいくつかご紹介します。
1. 機能的な稼働率を検証する
多くの事業で、APIの可用性や稼働時間を監視することで、そのデータがAPIサービスの質を測る基準として利用されています。しかし、API経由で発生する様々なタイプのデータ交換トランザクションに対しては、API全体の可用性を測定するだけでは十分ではありません。すべてのアクション（Create、Read、Update、Deleteなど）の可用性とパフォーマンスを個別に監視し、すべてが機能していることを確認する必要があります。
これを行うには、マルチステップAPI監視機能を備えたモニタリングツールを実装できます。APIとデータの可用性を同時に引き上げるのに効果的です。ちなみに、このタイプのモニタリングではテスト用に限定された、事前の定義に基づくAPIコールが使用されます。そのため、実世界のトラフィックと合成モニタリングにおける入力内容は異なる可能性があります。
2. APIの依存関係を監視する
すべてのAPIが独立して構築されているわけではありません。多くの場合、自分のAPIを構築する際にサードパーティのAPIを利用する必要があります。自分のコードを深いレベルまで計測することはできますが、サードパーティAPIの動作を追跡することは忘れがちです。
実際には、サードパーティAPIからのレスポンスも追跡しなければなりません。個人的な経験からいえば、個々の独立した分析だけでなく、依存関係の不具合にも意識を向けるべきです。
3. APIモニタリングに自動テストを導入する
CI/CDパイプラインをきちんと設定しているのであれば、自動化の重要性はすでにご存知でしょう。これを一歩先に進め、モニタリングとあわせてAPIエンドポイントの自動テストもセットアップできればベストです。リリース前にエンドポイントの自動テストを実行するために、CI/CDパイプラインに個別のステップを追加することをおすすめします。基本ではありますが、今一度実装できているか確認してみてください。
4.強力なアラート機能のあるツールを選ぶ
さまざまなツールがあるため、その中からひとつを選ぶのは簡単ではありません。そこで、ひとつの目安として注目したいのが優れたアラート機能です。選択したツールが、問題について適切にアラートを出してくれなければ、何らかのイベントが発生したかどうかを確認するために、手動で確認する手間が発生します。この領域での自動化は、チームの生産性を向上させるために重要です。
5. CI/CDパイプラインに直接統合可能なツールを優先する
DevOpsプロセスの効率を分析するために、CI/CDパイプラインの各段階でモニタリングを統合することをおすすめします。そのためには、そのような機能を提供するツールを慎重に選択する必要があります。
気になるツールにその機能があるかどうかを確認するには、サードパーティとの統合についての一覧ページを探しましょう。JenkinsやGitHubなどのCIサーバーがサポートされていれば安心です。
6. APIのプライバシーを確保する
APIモニタリングツールの中には、サードパーティのSaaSプラットフォームを活用し、ファイアウォールで特定のポートを開いて、（通常であれば到達できない）内部APIのモニタリングを要求するものもあります。これは大きなセキュリティリスクをもたらすことになります。そのポートを知っていれば、誰でもそれを使ってシステムに不正アクセスすることができてしまいます。
だからこそ、APIの設計を考慮し、内部・外部を問わず各エンドポイントを安全に監視できる、優れたAPI監視ソリューションを選択することが不可欠です。このような理由から、利用するツールは（侵入者にアクセスを許さないために）不用意な余地を残すことなく内部APIに非公開でアクセスできるものにすべきでしょう。
7. 24時間365日監視を行う
APIを常時監視していないと、莫大な損失を被る可能性があります。どんなサービスでもダウンする可能性をゼロにすることはできません。ダウン発生時に監視サービスが機能していなければ、問題の把握に遅れが生じます。顧客からの信頼や新たな収益のチャンスを失うことにもなりかねません。
機能テストには少なくとも1時間に5回、セキュリティとOAuthのモニタリングには1時間に1回、高頻度のモニタリングを設定することをお勧めします。
8. 内部監視よりも外部監視を優先する
問題は内部と外部で一様に発生するわけではありません。システムのファイアウォール内で再現できない問題にユーザーが直面することもあります。その場合、内部メトリクスが正しく機能しているかどうかは問題ではなく、ユーザーが製品にアクセスできないと、すべての運用メトリクスが意味をなしません。
このようなケースを避けるために、常に内部監視よりも外部監視の設定を優先してください。ユーザーが直面する問題を解決するには、ユーザーの視点からAPIを監視する必要があります。
9. すべてのリソースを監視する
APIの背後にあるサービスやアプリケーションを構築する過程で、基本的なまたは複雑なコンポーネントを設計することになるでしょう。個々のコンポーネントの監視をスキップしたくなることもあるかもしれませんが、そのような考えは推奨されません。単純なコンポーネントの一見些細なエラーが、大規模なアプリケーションを壊してしまう可能性があります。
あらゆるところに目を配ることで、問題の原因となったコンポーネントを手間なく見つけられます。
10. すべてのレスポンスパラメータを分析する
ステータスコードが200を返したかどうかだけをチェックするのでは不十分です。多くの人が、200は成功、500はサーバーエラーといった基本的なHTTPステータスコードを基準に使っているのではないでしょうか。しかし、成功やエラーの中には様々なバリエーションがあり、APIがどのように機能しているかを判断するには、これらの各インスタンスを追跡することが不可欠です。
また、APIから返されるコンテンツのサイズの変化にも目を凝らすべきです。通常のレスポンスのサイズが500kbであるにもかかわらず、100kb以下しか受け取らなかった場合、何らかの障害の発生が考えられます。
API監視ツール
上記のベストプラクティスを実践するには、APIモニタリングソリューションについての検討から始めることになります。WordPressなどであればAPIモニタリングにすぐに使えるプラグインがありますが、純粋にコードを記述して構築したアプリケーションであれば、より本格的なソリューションを探すのが得策です。
次のセクションでは、おすすめのAPIモニタリングツールをいくつかご紹介します。
Uptrends
Uptrendsはウェブアプリ、API、サーバー、その他多くの監視を担うサービスです。Microsoft、Vimeo、Volkswagenのような著名な企業を含む、2万5,000を超える組織で導入されています。
最も顕著な特徴として、ブラウザベースのテストが組み込まれています。独自のブラウザを使用してアプリやウェブサイトを実行し、そのパフォーマンスに関する詳しいデータを取得できます。
しかし、レスポンスタイムやデータの取得だけがこのサービスの強みではありません。Uptrendsを使用すると、各リソースに関する詳細なパフォーマンスレポートも生成でき、システムで発生する可能性のあるあらゆる種類のボトルネックを早い段階で把握することができます。各エラーについてスクリーンショットが撮影されるため、発生したエラーをそのまま直感的に確認可能です。
Dotcom-Monitor
Dotcom-Monitorでは、HTTPまたはHTTPSジョブを使用してマルチタスク監視デバイスを構成可能です。これにより、Web APIの可用性、応答状況、パフォーマンスを監視できます。
Dotcom-Monitorエージェントが、1つまたは複数のクライアントリクエストをレプリケートし、APIとクライアントの間でデータが適切に交換できているかどうかを検証します。エージェントがエラーを検出すると、設定したフィルタの中身と照合しチェックが実施されます。エラーがフィルタリングで除外されない場合には、エージェントからアラートが送信されます。
このツールでは、アラートスケジュールやエスカレーションの選択肢をカスタマイズすることができます。CSV、PDF、TXTなど、さまざまな形式でエラーレポートをエクスポート可能です。Dotcom-Monitorのエラーレポートには、ダウン、レスポンスタイム、ロケーション別の平均パフォーマンスなどの詳しい情報が表示されます。
Dotcom-MonitorはAPIモニタリングソリューションの中では手軽な部類に入り、そのプランは月額1.99ドルからです。予算が限られている企業にとって、Dotcom-Monitorは注目のAPIモニタリングサービスでしょう。
Graphite
GraphiteはオープンソースのAPIモニタリングシステムです。データをGraphites Carbonコンポーネントにプッシュすることで、APIから関連データを取得することができます。Graphiteがこのデータをデータベースに保存し、そこから洞察を引き出す役割を果たします。
Graphiteは、インストールプロセスのシンプルさで高い人気を誇ります。独自のデプロイメントシステムであるSynthesizeを使うことで、スタックの自動インストールと設定スクリプトの処理を行うことができます。
Graphiteでは、任意のイベントを保存可能です。そのイベントは一般的に時系列のメトリクスに関連したものになります。また、アプリケーションやインフラストラクチャのデプロイメントをGraphite内に追加して追跡することで、開発チームは問題やボトルネックの原因を素早く発見し、予期しない動作につながるイベントや異常についてより多くのコンテキストを把握することができます。
Sematext
SematextはDevOpsの間で人気のあるソリューションで、これには監視ツール一式が備わっています。APIモニタリングは、Sematext Syntheticsという名前の合成モニタリングサービスの一部です。
Sematextは複雑なAPIモニタリングとアラートシステムを備え、さまざまなエラーやメトリクスに基づいて動作するようにカスタマイズできます。このツールを設定すると、アラートを送信する前に二重、三重のチェックを行うことが可能です。アラートから誤検出を排除し、正確な情報のみを精査できます。
SematextにはHTTPモニタリングに加えて、包括的なブラウザモニタリング機能も搭載されています。この機能により、ウェブアプリに対する、スクリプト化したユーザーインタラクションに基づくウェブパフォーマンデータの収集が可能になります。つまり、ページの読み込み時間、Largest Contentful Paint（LCP）時間などを追跡する通常のテスト基準の枠をこえて、アプリ内の認証フロー、検索クエリの実行、カートからのアイテムの追加または削除など、詳細なエミュレートに基づきユーザーインタラクションの調査に有用です。Sematextではすぐに利用を開始し、このようなさまざまなユーザーインタラクションについてのデータを取得できます。
BlazeMeter
BlazeMeterは、モダンアプリケーションに対応した、エンドツーエンドのテストおよびモニタリングツールです。これを使うことで、オープンソースのテストフレームワークを自由に選択し、シンプルなダッシュボードを介して分析することができます。また、Apache JMeterとのシームレスな統合が可能で、複雑なウェブアプリケーションでも問題のない優れたパフォーマンス測定ツールだと言えます。
ほとんどのAPIモニタリングソリューションと同様に、BlazeMeterにも機能テスト（「シナリオ」と呼ばれる）のような基本的な性能が備わっており、インタラクティブなグラフィカルユーザーインターフェースを使って設定可能です。BlazeMeterは、専用のテストツールTaurusを通じてDSL（ドメイン固有言語）を公開しているため、開発者は汎用的なテストを記述できるようになっています。そして、これらのテストをJMeterやその他のオープンソースツールを用いて実行することも可能です。
BlazeMeterの設計を考慮し、価格は高めに設定されています。同時ユーザーが5,000人を超えるアプリの場合、月額600ドル以上の出費を覚悟する必要があります。ただし、使用量に応じた固定料金プランを選ぶこともできます。
御社の製品がPhizer、Adobe、NFL、Atlassianなどのラインであれば、BlazeMeterは優れたAPIモニタリングソリューションとなるでしょう。
今回はAPIモニタリングツールを簡潔にご紹介しましたが、実際にはこれ以外にもたくさんの選択肢があります。GeekflareやSematextによるAPIモニタリングについての解説（英語）も参考になるはずです。
まとめ
APIは現代のコンピューティングマシンに欠かせない縁の下の力持ちです。ソフトウェア市場のほとんどの製品には、サードパーティツールとのシームレスな統合を可能にするAPIが付属しています。スムーズなユーザー体験を提供し、顧客を維持するためには、ソフトウェア製品と共にAPIの構築を真剣に検討する必要があります。今回は、基本的な概念、ベストプラクティス、おすすめのAPIモニタリングツールなど、技術の基本をご紹介しました。ウェブリソースの通信についても、理解を深めていただけたのではないでしょうか。
しかし、APIとAPIエンドポイントを使ってできることは、まだまだたくさんあります。APIエンドポイントに関する知識とスキルを広げるために、もっと深く掘り下げて学習を続けることをおすすめします。
