レスポンスの検証

Apidogでは、APIへリクエストを送信した後、自動的にレスポンスが仕様に準拠しているかを検証します。

検証ルール

検証項目	プロパティタイプ	検証メッセージの例
必須キーの存在確認	すべて	$には必須プロパティ「code」が必要です
値の型の一致	すべて	$.data.idは整数である必要があります
非null項目のnull値チェック	すべて	$.data.idは整数である必要があります
列挙値の範囲チェック	文字列、整数、数値	$.data.statusは定義された値の1つである必要があります（使用可能な列挙値：available、pending、sold）
数値の範囲チェック	整数、数値	$.data.idは0以上である必要があります
数値の倍数チェック	整数、数値	$.data.quantityは10の倍数である必要があります
文字列長の範囲チェック	文字列	$.data.nameは3文字以上である必要があります
文字列のパターン一致	文字列	$.data.nameは「^[A-Za-z]」のパターンに一致する必要があります
配列要素数の範囲チェック	配列	$.data.tagsは2項目以下である必要があります

上記の項目に問題がない場合、「レスポンスデータ構造の検証が成功しました！」と表示されます。これは、実際のAPIの戻り値がAPI仕様書と一致していることを意味し、手動での確認が不要になり、効率が向上します。

右側に対応するメッセージが表示された場合、そのメッセージに従って問題を解決できます。

主に2種類の問題があります：1つはサーバーからのレスポンスが正しくない場合で、バックエンドを仕様に合わせて修正する必要があります。もう1つはAPI仕様が間違っている場合で、APIの仕様を修正する必要があります。

自動検証機能を利用することで、レスポンスを検証するスクリプトを手動で書く必要がなくなります。さらに、API仕様が変更された場合でも、検証は自動的に更新されます。

デフォルトでは、ApidogはAPIの最初のレスポンス（通常は200レスポンス）を検証します。ただし、APIは複数の異なるレスポンスと異なるスキーマを返す場合があります。その場合、検証エリアの右上で検証するレスポンスを選択できます。

また、レスポンスの前にある切り替えボタンをクリックして、「検証」機能をオフにすることもできます。この変更は現在のAPIにのみ適用されます。

ビジネスの更新に伴い、レスポンスに追加のプロパティが加わることがあります。このような場合、Apidogでは追加フィールドを許可するかどうかをユーザーが決定できます。

例えば、ユーザー情報を照会するAPIがあり、以前の戻り値は「name」と「phone」でした。そのため、データ構造は以下のように指定されていました：

ビジネスのアップグレードにより、このAPIに新しい「city」フィールドが追加されましたが、API仕様は更新されませんでした。デフォルトの検証メカニズムでは、エラーは報告されません。これは、追加フィールドがデフォルトで許可されているためです。

ただし、より厳密な開発シナリオでは、定義と一致しない追加フィールドがある場合にエラーを報告する必要があります。この場合、以下の手順で実現できます：

API仕様のレスポンスを修正します。「object」の詳細設定で「additionalProperties」を「Deny」に設定します。これは現在のAPIにのみ適用されます。

「レスポンス検証」スイッチはデフォルトでオンになっており、プロジェクト設定画面の「検証レスポンス設定」で調整できます。この設定は現在のプロジェクト内のすべてのAPIにのみ適用され、保存済みの「Endpoint Cases」には影響しません。

手動のアサーションやポストスクリプトのみが必要で、ApidogによるAPI仕様との整合性検証が不要な場合は、特定のモジュールの検証機能を無効にできます。

検証レスポンスには「HTTPステータス」、「Header」、「Body」が含まれており、プロジェクト設定の「レスポンスコンテンツの検証」で調整できます。この設定は現在のプロジェクト内のすべてのAPIにのみ適用され、保存済みの「Endpoint Cases」には影響しません。

Last modified: 2 months ago