はじめに

とは何か ZEST 仕様（Zspec）？

Zspec - ZEST 仕様ファイルは Xml ファイル 事前に定義された Xml スキーマ (xsd). スーパーセットです。 OpenAPI3.0 i.e ZEST オープン Api 3.0 が提供するすべてのサポートがあります。作成する Zspec - ZEST 仕様書 ファイルは、使用する重要な必須ステップです。 ZEST 設定がその構成要素（ソースコードとSdkの生成）の基盤を築くため、 automation testing ヘルプドキュメント）。

なぜZspec？

ZSPECはOpenAPI3.0のスーパーセットです。 OpenAPI3.0のサポートに加えて、ZSPECはプロパティ/キーで以下のサポートを提供します。

1.1. 「余分な値検証」を使用した自動品質チェックを有効にする

ユースケース フィールドを検討する 部門別 可能な値のリストを次のように指定します。 「機械」 、 「エレクトロニクス」 そして 「コンピュータサイエンス」. シナリオ 1: 新しい値を許可する ユーザーが値を入力すると、 『市民』 （この3つの値を除いて）、要件は 新しい値を許可する. ここでは、要件は次のとおりです。 追加値を許可する フィールド用 部門別. — シナリオ 2: 新しい値を拒否する ユーザーが値を入力すると、 『市民』 （この3つの値を除いて）、要件は 新しい値を拒否する.ここでは、要件は次のとおりです。 追加値を拒否する フィールド用 部門とショーエラー. — シナリオ 3: デフォルト値を割り当てる ユーザーが値を入力すると、 『市民』 (これらの 3 つの値を除いて)、要件は デフォルト値.ここでは、新しい値を無視し、 デフォルト値を割り当てる フィールド用 部門とショーエラー.これらのシナリオでは、フィールドの追加値を処理する必要があります。 部門別 そしてこれらはすべてを使用して達成することができます ZEST 仕様書形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、特定のプロパティの追加値を処理できます。 可能な値はマップデフォルト、拒否、許可です。

1.2. 「条件付きリクエストとレスポンス」を使用したカスタマイズされた Api インタラクションの実現

A. リクエスト条件

ユースケース フィールドを考慮する 国 、 郵便番号 そして 郵便番号. 要件は

• 国があるときはいつでも 「インド」 を指定すると、要求本文を作成する必要があります。 郵便番号 そして

• 国があるときはいつでも 「Us」 を指定すると、要求本文を作成する必要があります。 郵便番号. ここで要件は、の値に基づいてリクエスト本文を構築することです。 国.このユースケースは、 ZEST 仕様書形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、カスタム基準に基づいてリクエストの本文を作成できます。

B. 応答のための条件

ユースケース フィールドを考慮する 国 、 郵便番号 そして 郵便番号. 要件は

• 国がである場合 「インド」 、次に、応答が 郵便番号 そして

• 国がである場合 「Us」 、次に、応答が 郵便番号 ここで要件は、国の価値に基づいて応答を検証することです。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、基準に一致するように応答を検証できます。

1.3. 「無効な値検証」でデータの整合性を確保する

ユースケース フィールドを考慮する 「ユーザー名」 サインアップ形式で 有効なユーザー名に次の基準を定義したとしましょう。

• ユニークであるべきです

• 最小長さは9でなければなりません

• 特殊文字で始まるべきではありません シナリオ 1: デフォルト値を割り当てる ユーザー名がこれらの条件を満たしていない場合、要件は条件を満たす自動生成されたユーザー名を割り当てることです。ここでは、要件は次のとおりです。 デフォルト値を割り当てる フィールドのユーザー名に移動します。 — シナリオ 2: 値を拒否する ユーザー名がこれらの基準を満たしていない場合、要件は値を拒否することです。ここでの要件は、あなたの基準を満たしていない値を否定することです。上記のシナリオでは、デフォルト値を割り当てるか、値を拒否して、値が条件とハンドルに従っているかどうかを確認する必要があります。 このユースケースは、 ZEST 仕様書形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、デフォルト値を割り当てたり、値を拒否したりすることで、基準を満たさない値を処理できます。

1.4. 「データパスプロパティ」を使用した簡単なデータ取得

ユースケース ゾーホCrmでは、すべてのアカウントが持っているカスタムモジュールと一緒に標準モジュールのセットがあります。 apiを処理する際に、すべてのモジュールのapi名のリストを取得するとします。ここでは、特定のパスから値を選択する必要があります。 このユースケースは、データパス = $.モジュール. Api_名を使用して達成できます。 ZEST 仕様のフォーマット。Zspecを使用すると、apiは指定されたパスから値を取得できます。

1.5. データの完全性「空きプロパティ」を実現

ユースケース Abcという組織を考えてみよう。 すべての従業員は、 従業員Id. あなたは許可したくない 空っぽ このフィールドの値。 ここで要件は、フィールドの従業員 Id の空の値を拒否することです。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Api のすべてのリクエストとレスポンスで空の値を許可または拒否できます。

1.6. 「ユニークなプロパティ」とのデータの区別を維持する

ユースケース Abcという組織を考えてみよう。 すべての従業員は、 従業員Id.許可したくない 重複 このフィールドの値。 ここでは、フィールドの従業員 Id の重複値を拒否する必要があります。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Api のすべてのリクエストと応答の値が一意であるかどうかを定義できます。

1.7. 「プロパティに含める」を使用して検証をカスタマイズする

ユースケース フィールドを考慮する 「メール」 サインアップ形式で 要件は、アカウント作成操作中にのみメールの検証を実行することです。 ただし、顧客の詳細の更新などの他の操作では、メールの検証は必要ありません。 ここでは、リクエストの作成操作中にのみメールの検証を有効にします。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、リクエストの特定の操作または応答の特定の操作に対してのみ検証を実行できます。

1.8. 「追加のプロパティ名と値の検証」で Api の構造を強化する

ユースケース Crm の変数に似たシナリオを考えてみましょう。 要件は、名前の最大長を15に、値を50に制限することです。ここでは、追加の変数を許可する必要がありますが、これらの変数が保持する値の長さに制限を課します。Zspecを使用すると、追加のプロパティを許可し、これらのプロパティが保持する名前と値に制約を追加できます。

2. リソース構成

ユースケース Abcという組織を考えてみよう。 すべての従業員は、 従業員Id. このフィールドをプライマリフィールドとして設定します。ここで要件は、 従業員Id 主な財産として。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。この要素を使用して、リソースのプライマリ プロパティを定義できます。

3. パス設定

ユースケース すべての製品の主キーを持つeコマースプラットフォームを検討してください。 「製品Id」. 残業、このプラットフォームはサードパーティのベンダーとも協力しています。 これで、主キー定義を上書きする必要があります。 したがって、要件は、 「ベンダー製品Id」 列は、サードパーティ製品のプライマリフィールドである必要があります。 ここでは、リソース設定で定義されたプライマリ プロパティを上書きします。 これは、を使用して達成できます。 ZEST 仕様のフォーマット。この要素を使用して、リソースのプライマリ プロパティを定義できます。 リソース設定で定義したプライマリ プロパティを上書きし、そのパスを言及することもできます。

4. エラー条件

ユースケース フィールドを考慮する 場所 天気データApi 要件は、データベースに場所が見つからない場合は、応答をエラー応答として定義することです。ここでは、Api のエラー条件を定義します。 これは、を使用して達成できます。 ZEST オープンApi 3.0を使用しない仕様形式。このプロパティを使用して、Api の応答をエラーにする条件を定義できます。