APIコールとは？

APIコールの意味

ご存知の通り、APIは、二つのアプリ間でデータをやりとりするために必要な仕組みです。APIが他のアプリへデータや機能のアクセスを依頼する際、それをAPIコールと言います。 

構造的には、あるAPIがサーバに送るメッセージで、他のアプリのAPIと接続するためのものです。特定の情報へ効率よくアクセスするための命令や依頼のようなものと考えてよいでしょう。

APIコールとリクエストは、ほぼ同じ意味です。 

以下に、APIコールの意味を分かりやすく示す例を紹介します。

例えば、Googleで「ドバイ行き最安フライト」を検索したとします。

リクエストを受けると、Googleは各サービス提供者にAPIコールを送り、料金や空き状況を確認します。結果はAPI形式で提供され、Googleがそれを受け取って画面に表示します。これらは即時に行われます。

APIコールの仕組み 

APIコールが発生すると、必ずAPIエンドポイントが定められます。APIエンドポイントとは、コールが送られる先や受信するリソースのことです。多くの場合、これらはサーバやWebアプリとなり、コールの受付、処理、情報の収集、応答の返答を担います。

目的のエンドポイントに届くために、各APIコールにはURIが付与されます。これは、正しい宛先を識別する業界標準です。状況に応じて、URIはサーバ、アプリ、メールアドレス、あるいはWebサイトであることもあります。

Web APIの場合、URIはURLとなります。これはインターネット上の宛先を示し、HTTPやHTTPSといったアプリ層プロトコルを含むことが理想です。HTTPSはHTTPより安全で、APIセキュリティに関心のある企業が主に利用しています。

しかし、ほとんどのWeb APIがHTTPベースであるため、HTTPコールが一般的です。これらはPOST、PUT、GETといった標準HTTP動詞を用い、どのような情報を求めるかを示します。

APIコールの例

APIはあらゆるアプリの裏方として機能しているため、APIコールはあらゆる場所で利用されています。ここでは、Facebookを例にAPIコールの具体例を見てみます。  

GET https: //api.facebook.com/1.1/followers/user_id.json

このAPIコールは、エンドポイントのみが定義されているため、単独では結果を出しません。迅速かつ的確な結果を得るため、リクエストに多様なパラメータを追加することが可能です。

もう少し複雑な例を以下に示します。 

GET https: //api.facebook.com/1.1/followers/ids.json?cursor=-2&screen_name=smartsandy&count=1000

この一つのAPIコールで、様々な動作が実行されます。例えば、cursorが-2に設定され基本的なページネーションが行われ、screen_nameパラメータで「smartsandy」というユーザが指定されます。

3番目のパラメータcount=1000は、一度のリクエストに含まれるFacebookユーザIDの総数を制限し、データの溢れを防ぎます。

‍

APIコールの実行方法?

サービス同士の通信はコールによって行われ、APIは認証されたサービス間のやりとりを仲介します。正しい手順に従えば、APIコールは容易に実行できるのです。以下に手順を示します。

1. Step. 対象ソフトのURIを確認する

APIコールを行う最初のステップは、データを取得する対象のソフトまたはプログラムのURIを把握することです。

家に住所があるように、サーバやソフトにはURIがあります。これにより、APIコールの送信先が明らかになります。  

なお、各APIはそれぞれ異なるエンドポイントを持ち、固有のパスが設定されています。

2. Step. APIコールにHTTP動詞を付与する

URIの詳細を確認した後は、APIリクエストの構成を理解する必要があります。リクエスト動詞をAPIコールに挿入することから始まり、代表的な動詞は次の通りです:

• GET：リソースの取得に用いる
• POST：新たなリソースの生成に用いる
• PUT：既存リソースの編集・更新に用いる
• DELETE：不要なリソースの削除に用いる

各動詞はAPIに異なる動作を指示します。例えば、Wallarmプラットフォームの主要ツールの詳細を、公式APIでバージョン「1.0」として取得する場合、GETリクエストは以下のようになります:

GET https: //call.example.com/api/top-tools /v1/list.json?api_key=XXXXXXXXX&version=1.0

このAPIリクエスト動詞により、バージョンが「1.0」の主要なCallツールリストを取得できます。リストが存在すれば、JSONまたはXML形式で詳細が返され、コード200は正常を示します。

リストが存在しない場合は、コード404が返されます。

JSON形式の応答が理解しづらい場合、Excelに変換することでWallarmツールのリストが確認できるでしょう。

3. Step. APIコールにヘッダーを追加する

ヘッダーは、送信されたAPIコールと期待される応答についてAPIに指示を与えます。ヘッダーがなければ、APIコールは適切な送信先を決められません。一般的に追加されるヘッダーは次の3種類です:

• User-Agent

User-Agentは、バージョン、リリース情報、OS、ベンダー、アプリなどの主要な情報を含み、サーバがAPIコールの内容を深く理解するために役立ちます。これにより、情報交換が円滑になります。

• Content-Type

Content-Typeは、APIコールのコンテンツ形式、たとえばJSONかXMLかを示すために使用されます。これがないと、APIはリクエストの意味を正しく解釈できず、応答が返されなくなる恐れがあります。 

• Accept

Acceptヘッダーは、API利用者が受け取りたい応答形式を定めるために用います。指定がなければ、希望する形式とは異なる応答が返される可能性があります。

4. Step. アクセストークン/APIキーを付与する

アクセストークンやAPIキーは、APIコールの識別を容易にするために使用されます。これらは固有の番号や文字列を持ち、送信先のリソースを特定します。APIキーやアクセストークンは、クライアントが許可した範囲内でAPIリクエストを受け入れるか否かを判断するために役立ちます。 

5. Step. 応答が返されるまで待つ

全ての手順を踏めば、すぐに応答が返されます。返されるコードにより、処理が成功したのか失敗したのかが分かります。一般的には、2XXコードが成功、4XXコードがエラーを示し、XXはこれらコードの複数バージョンが存在することを意味します。

以下に例を示します:

• 2XXコード

すべての2XXコードは成功を意味します。例えば、200 OKはリクエストが完了したこと、201 Createdはサーバで新規作成が成功したこと、202 Acceptedはリクエストの受領成功、204 No Contentは処理は成功しているものの返す内容がないことを示します。

• 4XXコード

前述の通り、4XXコードはエラーを示します。代表的な400は不正なリクエストを意味し、リクエストに何らかの誤りがある場合に返されます。その他のコードは:

401: Unauthorized。クライアントにこのリソースの要求権限がないことを示します。

403: Forbidden。リクエスト自体は正当ですが、対象のリソースへのアクセスが禁止されていることを意味します。

‍404: Not Found。最も一般的なエラーで、要求されたリソースが存在しないことを示します。

‍

APIコールをどう守るか 

適切なセキュリティ対策が施されていないAPIコールは、APIセキュリティや連携するIT基盤に大きな脅威となります。不十分な管理により、攻撃者は以下のような行為を行う恐れがあります:

• DosまたはDDoS攻撃：正規ユーザのアクセスを制限するため、一つのAPIに大量のAPIコールを送り込む攻撃です。これにより、APIが混雑し応答しなくなります。
• 各種脆弱性の悪用攻撃：既に脆弱なAPIの弱点を突き、機密情報の取得や特定APIへのアクセス妨害を試みる攻撃です。

このため、APIコールを守ることは極めて重要です。セキュリティ専門家が採用する一般的な対策は以下の通りです:

• APIエンドポイントを把握し、APIコールの行き先を確認する。
• API認証を用いて送信元が検証済みであることを確認する。相互TLSや公開鍵暗号方式が利用可能です。
• 有用なAPIセキュリティプラットフォームを活用する。Wallarmは、REST APIコールやSOAP APIコールを含む主要なAPIコールのセキュリティを一括で管理できる、包括的なプラットフォームです。

‍

おわりに

APIはAPIコールなしでは機能しません。APIエコシステムの重要な要素を軽視せず、APIセキュリティポリシーに組み入れることが大切です。APIコールが守られれば、確かな結果が生まれます。