APIコールを徹底解説：制限と最適化のポイント

## はじめに
APIコールはクライアントがサーバーのAPIにアクセスすることを指し、適正利用にはエンドポイントやメソッドなどの仕様理解が不可欠です。Apidogを使うと、APIコールの作成と大量処理が簡単になります。コール数制限を理解し適切に利用しましょう。

:::note info
もし、APIやアプリケーションを開発しており、強力なAPIツールとのシームレスな統合が必要であれば、ぜひ無料でApidogをお試しください！[Apidog](http://www.apidog.com/jp/?utm_source=opr&utm_medium=a2takuya)は、洗練されたユーザーインターフェースの構築に集中しながら、APIのスムーズな連携を実現するための理想的なツールです。
:::

## APIコールとは
APIコールとは、[APIリクエスト](http://apidog.com/jp/blog/how-to-create-and-send-api-request/)かAPIの呼び出しの別称になります。APIコールとAPIリクエストとAPI呼び出しといった概念も同じく、クライアントからデータをサーバーに送信してレスポンスを取得するという流れを探しています。

APIコールという概念の由来といえば、英語の「Call API」を日本語に直接に変換することになります。そこで、APIコールを「APIリクエスト」と「[API呼び出し](http://apidog.com/jp/blog/how-to-call-apis/)」として理解しても良いのでしょう。

## APIコールの基本実装
APIコールを正しく実装する、つまりAPIを正確に呼び出すには、サーバーから意図通りのレスポンスを取得する必要があります。一般的には、正しいAPIコールの実装方法は以下の流れに従う必要があります：

- APIのエンドポイント(URL)を確認する
- メソッド(GET、POSTなど)を確認する
- 必要なパラメータ(クエリパラメータ、パスパラメータ、httpボディなど)をリクエスト送信時に含める
- 認証(APIキーなど)が必要な場合は設定する


ただし、異なるAPIを正しくコールできる要件が随分違っています。正しくAPIコールを実装して、正確的なレスポンスを取得するために、それぞれのAPI仕様書を確認する必要があります。

### 実装の具体例
例えば、Notion APIのページ取得APIの仕様書を例にとって、正しいAPIコールの実装方法を皆さんに紹介してみたいと思います。

#### 送信先の確認
一番先に確認すべきなのは、[APIのエンドポイント](http://apidog.com/jp/blog/api-endpoint-and-its-testing/)です。APIのエンドポイント(endpoint)とは、APIを利用するためにアクセスするURI(Uniform Resource Identifier)のことで、APIコールの送信先だと理解しても良いのです。APIエンドポイントは通常、プロトコル、ドメイン、パスパラメータから構成されます。例えば、Notionのページ取得APIのエンドポイントは、`https://api.notion.com/v1/pages/{page_id}` になります。

![notion-api-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/5992ab10-53b3-b628-a37d-08369ecd8f0d.png)


ここでプロトコルは、`https` になり、ドメインは`api.notion.com` になり、パスパラメータは `/v1/pages/{page_id}` になりますね。

#### メソッドの確認
APIをコールしようとする時に、[HTTPメソッド](http://apidog.com/jp/blog/introduction-to-http-method/)（APIコールのメソッド）も非常に重要です。違う操作を行うために、適切なHTTPメソッドを選択する必要があります。

- GET（コンテンツを取得）
- POST（コンテンツを新規追加）
- PUT（既存コンテンツを変更）
- DELETE（コンテンツを削除）


#### 必須パラメータ
APIコールは、どのようなメソッドを使ってどこに送信することを確認した以上、何かを送信するかを確認する必要があります。

同じくNotionのページ取得APIを例にとる場合、「**PATH PARAMS（パスパラメータ）**」、「**QUERY PARAMS（クエリパラメータ）**」、「**HEADERS（ヘッダー）**」が必要です。それに、「QUERY PARAMS（クエリパラメータ）」に「required（必須）」が付いていないので、それを記入しなくても良いことを意味します。

![noiton-api-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/ab40f3ee-a1ca-c523-5e3b-56a7b72d4cbd.png)

パスパラメータは、すでにエンドポイントのURLに記入されているので、ここでHEADERS（ヘッダー）を記入して送信すると、正確なレスポンスを取得できるはずですね。

#### 認証の確認
また、多くのAPIは、アクセス制御やセキュリティを確保するための認証と認可の仕組みを提供します。これにより、APIを利用するためにユーザーが認証情報を提供したり、アクセス権限を持っているかどうかを確認したりします。OAuth、トークンベースの認証などが一般的な認証の手法です。

認証が必要となるAPIの場合、API KeyやAPIトークンなどの取得方法は、それぞれの公式ドキュメントで確認する必要があります。

## APIコール数の制限
上記の内容のように、API仕様書で決められている規則に従って、APIを正しくコールすることができます。が、いろんなAPIでは、過剰な負荷を防ぐために、コール数に制限が設けられています。これは、「APIコール数の制限」と言われています。APIコール数の制限は、クライアント側とサーバー側でも設けられている場合があります。

### クライアント側の制限
APIクライアントプログラム側で、1日あたりや1時間あたりのリクエスト送信回数をコードでハード制限することがあります。このような制限が設けられている理由といえば、主に次のようになります：

- サーバーへの過剰な負荷を防ぐため
- 制限数はクライアント側の設計によって異なる
- 制限に達すると以降のリクエスト送信を抑制する

### サーバー側の制限
また、APIを提供するサーバー側が、クライアントからのリクエスト受付数を制限することもよく見られています。一旦サーバー側のリクエスト受付数の制限に達すと、クライアントからどのようにリクエストを送信しても、レスポンスがエラーになります。サーバー側でコール数制限を制限する理由は次のようになります：

- サーバー負荷防止、過剰利用防止など
- 制限数はサービスのプラン等によって異なる
- 制限超過時はエラーを返すかレート制限をかける
- クライアント側での対応は困難で、提供元と交渉やプラン変更が必要になる


このようにクライアント側とサーバー側で制限の意味合いや対応は異なります。サービス品質を維持するためには両者の制限を理解し、適切に対応することが重要です。


## ApidogでのAPIコール拡張
それでは、次はAPIコール数に制限がないAPIクライアントツールのApidogを使って、APIコールを簡単に実装する方法を皆さんに紹介していきます。非常に直感的で使えるAPIクライアントのApidogを使うなら、次のように簡単な数ステップだけで、APIコールを実装できます。

**ステップ⒈**Apidogを開き、「**＋**」**ボタン**をクリックして、「**新しいRequest**」を選択して、リクエストを新規に作成します。

![notion-request-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/46b33c0d-ee2c-6175-21b2-0bcb4b46112a.png)

ステップ⒉同じくNotionのページ取得APIを例にとって、HTTPメソッドをGETにして、エンドポイントの`https://api.notion.com/v1/pages/{page_id}` を入力します。

![notion-request-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/6d24d247-2ca3-3d78-b02f-d19022e3a6cb.png)

**ステップ⒊**このAPIの仕様書に記載されているように、HEADERS（ヘッダー）に「Notion-Version」を記入して、送信ボタンをクリックして、APIをコールして、レスポンスを取得できるようになります。

![notion-request-5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/5f1b11e3-c39e-e9f1-b17b-034980d0d3ab.png)

### 一括実装の方法
また、特に大きなプロジェクトの中、複数のAPIコールを一括に実装する必要がある場合、ApidogというAPIクライアントによっても簡単に実現されることが可能です。

Apidogの自動テスト機能を使って、APIコール数がいくらあっても、同時に一括処理することもできます。

**ステップ⒈**左側のメニューから「**自動テスト**」を選択して、「**テストのシナリオを新規作成**」して、「**ステップを追加**」をクリックすると、APIコールをテストステップとして追加することができます。

**ステップ⒉**このモジュールでは、ステップ数の上限がないので、APIコール数がいくらあっても追加することができます。その後、「**実行**」ボタンをクリックして、各APIを追加順に従ってコールできます。

![test-steps-6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877124/fd69447c-9bc8-43ff-e5f7-4596e976809f.png)

そして、「**往復回数**」を設定すると、全てのステップが繰り返して実行されるので、非常に便利です。

## 終わりに
APIコールとは、クライアントからサーバーのAPIにアクセスすることを指します。正しくAPIを利用するには、エンドポイント、メソッド、パラメータ、認証などの仕様を確認する必要があります。APIのコール数にはクライアント側とサーバー側の両方で制限が設けられることがあります。過負荷防止などの目的でAPIの適正利用が求められます。

[Apidog](http://www.apidog.com/jp/?utm_source=opr&utm_medium=a2takuya)といったツールを使えば、簡単にAPIコールを作成・実行できます。また、テスト機能を使えば大量のAPIコールを一括処理することも可能です。APIを適切に利用するためには、コール数制限も含めて仕様を理解し、クライアント・サーバー双方の負荷に配慮することが大切です。

**最後まで読んでくださり、ありがとうございました！
この記事を読んで少しでも理解を深めていただければ幸いです！**