PostmanでREST APIをテストする方法

2026-09-12
による Đội Ngũ Toidayhoc
1 最小読み取り時間

PostmanでREST APIをテストする方法

REST APIリクエストを理解する

整理されたデスクの上に、接続されたリクエストパネルとレスポンスパネルが表示されたノートパソコン

Postmanを開く前に、APIが何を要求し、何を返すべきかを確認しましょう。通常、リクエストにはHTTPメソッド、URL、ヘッダー、クエリパラメータ、場合によってはリクエストボディが含まれます。たとえば、商品APIでは、商品42を取得するためにGET https://api.example.com/products/42を使用し、新しい商品を作成するためにPOST https://api.example.com/productsを使用します。

APIドキュメントを確認し、必要なメソッド、エンドポイント、認証方式、データ形式を書き出すことから始めましょう。サービスがJSON、フォームデータ、またはcategory=booksのようなクエリパラメータのどれを想定しているかを確認します。この準備により、どの設定が失敗の原因となったのか分からないまま複数の設定を同時に変更するという、初心者によくあるミスを防げます。

Postmanワークスペースと環境を作成する

整理されたAPIリクエストのフォルダーと環境設定が表示された1台のコンピュータ画面

プロジェクト用のPostmanワークスペースを作成し、Users、Products、Ordersなどのフォルダーにリクエストを分類します。関連するリクエストをまとめておくと、ワークフローを繰り返したり、結果を比較したりしやすくなります。小規模なプロジェクトでは10個程度のリクエストで済む場合もありますが、コレクションが数十個のエンドポイントに増えると、明確な整理が重要になります。

開発環境、ステージング環境、本番環境の間で変わる値には、環境変数を使用します。すべてのリクエストに完全なサーバーアドレスを入力する代わりに、ベースURLを変数として保存し、一貫して参照します。同じ方法でアクセストークン、ユーザーID、APIバージョンも管理でき、誤って別のサーバーにリクエストを送信するリスクや、繰り返し編集する手間を減らせます。

まずGETリクエストを送信する

GETリクエストは、通常、サーバーを変更せずにデータを読み取るため、最初の確認として有用です。エンドポイントを入力し、GETを選択し、必要な認証情報を追加して、リクエストを送信します。エンドポイントがhttps://api.example.com/users/15の場合は、サーバーが何かを返したことだけでなく、レスポンスがユーザー15を表していることを確認してください。

リクエストを送信した後、ステータスコード、レスポンスタイム、ヘッダー、ボディを確認します。200ステータスは通常、成功を示しますが、id、email、createdAtなどのフィールドについても、型と値が想定どおりであることを確認してください。レスポンスが空の配列の場合は、APIが壊れていると判断する前に、クエリパラメーターとテストデータを比較してください。

POST、PUT、DELETEを安全にテストする

読み取り操作が正常に動作してから、データを変更するリクエストを記述します。POSTリクエストでは、通常はraw JSONである正しいボディ形式を選択し、商品名、価格、在庫数量などの小さく有効なペイロードを送信します。サーバーがステータス201などの適切な作成レスポンスを返すことを確認し、返されたレコードに生成済みの識別子が含まれていることを確認してください。

有効なデータと同じように、無効なデータや境界値のデータも意図的にテストします。必須の名前を欠落させる、負の価格を指定する、極端に長い説明を入力する、無効な日付を指定するなどを試し、APIが破損したデータを作成するのではなく、明確な4xxレスポンスを返すか確認します。PUT、PATCH、DELETEリクエストでは、可能な限り専用のテストレコードを使用し、実際の顧客情報を変更したり削除したりしないようにしてください。

ステータスコード、ヘッダー、JSONを確認する

ステータス、ヘッダー、データの各セクションに分かれた、拡大表示されたAPIレスポンスパネル

ステータスコードだけでリクエストを判断しないでください。レスポンスヘッダーで、コンテンツタイプ、キャッシュの動作、リクエスト識別子、レート制限に関する情報を確認し、JSONが想定される場合はボディが有効なJSONであることも確認します。ステータスが200でも、HTMLのエラーページ、欠落したフィールド、または誤ったコンテンツタイプが返された場合、それはAPIを利用するクライアントにとってテスト失敗を意味します。

一般的なHTTPの結果に対して、現実的な確認を行います。有効なログインでは200、新しく作成されたリソースでは201、無効なリクエストでは400、認証情報の欠落では401、認証済みユーザーに権限がない場合は403が返されることがあります。これらのケースを区別することで、開発者はリクエストボディを何度も変更するのではなく、実際の問題を修正できます。

繰り返し実行できる確認のためにPostmanテストを追加する

探索中の手動検証は有用ですが、自動テストを使うと、繰り返し行う検証をより迅速に実行できます。Postmanでは、ステータスコード、レスポンスタイムのしきい値、コンテンツタイプ、重要なフィールドの有無を確認するテストを追加しましょう。たとえば、ユーザーエンドポイントでは、レスポンスが200であることと、返されたオブジェクトにidおよびemailの値が含まれていることを検証できます。

回帰を検出できる程度に具体的でありながら、脆弱にならないようにアサーションを設定しましょう。idが存在することを確認するほうが、特定の数値を永続的に期待するよりも、一般的に長期間維持しやすくなります。一方、emailが有効な形式に一致することを確認すれば、不正な形式のレスポンスを検出できます。コードを変更した後は同じコレクションを実行し、後続のすべての失敗にそれぞれ別の原因があると決めつける前に、最初の失敗を調査してください。

実践的なデバッグチェックリストで仕上げる

リクエストが失敗した場合は、メソッド、URL、クエリパラメーター、ヘッダー、認証、ボディを、ドキュメントと一つずつ照合してください。スラッシュの欠落、期限切れのトークン、誤った値が設定されたContent-Typeという名前のヘッダー、末尾にカンマがあるJSON構文など、小さな違いを確認します。エラーの原因をより簡単に切り分けられるよう、可能な限り最小限のペイロードでリクエストを再現してください。

コレクションを共有する前に、サンプルや保存済み変数から実際のパスワード、個人データ、本番環境のトークンを削除してください。重要な各リクエストについて、期待されるステータスコードと代表的なレスポンスを記録し、安全なテスト環境に対してコレクションを実行します。この最終確認により、Postmanは手動でSendをクリックするツールから、REST APIワークフロー全体を検証するための再現可能なチェックリストへと変わります。