API とは

API とは、あるプログラムが別のプログラムに何かを頼むための仕組みです。名前は application programming interface の略ですが、これを聞いてもほとんど何もわかりません。実際には、そしてこのチュートリアルでは、API は Web ページの代わりにデータでリクエストに応えるサーバーのことです。

スマートフォンの天気アプリは予報を保存していません。開くと、どこかのサーバーにリクエストを送り、気温や風速の数キロバイトの データを受け取って画面に描きます。サーバー側が API で、アプリはそのクライアントの 1 つです。

最初のリクエスト

このアドレスをブラウザのアドレスバーに貼り付けて Enter を押してください。

https://api.testingapis.com/api/Products/1

次のようなものが返ってきます。

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

ブラウザがサーバーにリクエストを送り、サーバーは商品番号 1 を探してその説明を返しました。この 1 回のリクエストと 1 回のレスポンスのやり取りこそ、API とのあらゆるやり取りの本質です。このチュートリアルの残りは、このやり取りの細部と、 サーバーがそれを正しく扱っているかを確かめる方法についてです。

このページからリクエストを送ることもできます。下の「送信」ボタンは、いまブラウザがしたのと同じことをして、ボディの上に レスポンスのステータスを表示します。このボタンはレッスンのあちこちに出てきます。

クライアントとサーバー

リクエストを送るプログラムがクライアント、応えるプログラムがサーバーです。クライアントはブラウザ、スマホアプリ、別の サーバー、コマンドラインツール、あなたが書いたテストのどれでもかまいません。サーバーにはそれらの区別がつきませんし、 つける必要もありません。リクエストを読み、仕事をして、返事をするだけです。

これはテストにとって重要です。サーバーはどのクライアントも同じように扱うので、ふだん話している相手のアプリがなくても テストできます。商品の価格が正しいか確かめるのに、ショッピングアプリの画面を 5 枚もたどる必要はありません。API に商品を尋ねて、価格を見ればいいのです。

エンドポイント

開いたアドレスは 2 つの部分からなります。https://api.testingapis.com はベース URL で、どのサーバーと話すかを 示します。/api/Products/1 はパスで、そのサーバーに何を求めるかを示します。サーバーが理解するパスの 1 つ 1 つをエンドポイントと呼びます。この API には数百あります。いくつか例を挙げます。

どんなエンドポイントがあるかは、API のドキュメントで調べます。この API の場合はAPI リファレンスです。実際のプロジェクトはここが大きく違います。丁寧なドキュメントがあるもの、コードから生成された OpenAPI ファイルがあるもの、書いた開発者がチャットに残したメッセージしかないものもあります。ドキュメントと API の食い違いに気づくのも、テストする人の仕事の一部です。

答えが「ノー」のとき

今度は存在しない商品を求めてみましょう。

サーバーはこう応えます。

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

これも正しいレスポンスです。商品 9999 は存在せず、サーバーはそれをはっきり伝えています。「見つからない」を意味する 404 のステータスと、どの ID がなかったかを説明するメッセージです。よい API は、応えられないリクエストも、応えられる リクエストと同じくらい丁寧に扱います。API テストの多くはここ、つまり異常系で行われます。開発者がいちばん時間をかけず、 バグがいちばん多い場所だからです。

なぜ API のレベルでテストするのか

アプリの画面からすべてをテストすることもできます。それでもチームが API を直接テストするのには、いくつか実際的な理由があります。

• 速いから。リクエストは数ミリ秒で終わります。画面をクリックして同じ状態にたどり着くには数秒かかり、そのクリックを自動化 するコードは書くのにずっと時間がかかるうえ、ボタンの位置が変わるたびに壊れます。
• たいてい API が先にできるから。バックエンドとフロントエンドは並行して作られることが多いので、クリックできるものが何も ないうちからバックエンドのテストを始められます。
• 画面は問題を隠すから。ショッピングアプリの数量欄に 1 から 10 までしか入力できないとします。その裏の API はふつうのリクエストを受け取るので、誰でも数量 -5 のリクエストを送れます。アプリが確認済みだとサーバーが信じていれば、 注文は合計金額がマイナスのまま通ってしまいます。これは API と直接話してみないと見つかりません。
• 1 つの API が複数のクライアントに使われることが多いから。Web サイト、iPhone アプリ、Android アプリ、パートナー連携などです。API のバグは、そのすべてのバグになります。

画面のテストにも役割はあります。画面が動くかを確かめる方法はそれしかありません。しかし、システムのルール（誰が何を見られる か、有効な注文とはどういうものか、在庫が切れたらどうなるか）は API にあるので、確かめるのも API です。