メリット

ソースコードを生成する

Api の概念を現実に変えることができます。 ZEST 仕様書（Zspec）。 バックエンドのソースコード(必要なクラス、ファイル、依存関係が含まれます)を取得できます。 AppSail そして機能。 この生成されたボイラープレートコードを使用して、開発者はカタリストを介してビジネスロジックのコードを追加できます。 AppSail そして機能。 このツールはワークフローを簡素化し、開発プロジェクトの進捗をスピードアップします。

Sdkの生成

触媒を使用して、世界中の Api と開発者の間のギャップを埋めることができます。 ZEST Sdkを生成しました。 このツールは、ワンクリックでさまざまな言語やプラットフォームにわたってapiの視野を広げます。 これは、zspec構成に基づいて複数の言語で正確なsdkを生成します。

自動化自動化

触媒 ZEST 重要なテストケースをアーキテクチャに基づいて構築し、開発者が必要なときにいつでもレポートを提供するために実行します。 また、アーキテクチャ内の未処理のエラーを特定してキャプチャし、完璧なApiの開発に貢献します。

包括的なドキュメントを作成する

使用 ZEST 、Api の細心の注意を払って作成された詳細な 3 ウィンドウ ドキュメントをダウンロードできます。 zspecで設定されたすべての構造と応答は、サンプルで文書化されます。 これにより、ヘルプドキュメントはすべてのユーザーの質問や懸念に対するワンストップソリューションになります。

Zspecで利用可能なサポート

Zspecファイルはxml形式で、単一のファイルで仕様を定義できます。 これには、ユーザーが必要とする api エンドポイント、リソースのプロパティ、ソースコードの入力、自動化、ヘルプ ドキュメントなどのホスト構成が含まれます。Zspec形式は Oas3.0のスーパーセット そしてそれは以下の追加のサポートを持っています。

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

ユースケース

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

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

A. リクエスト条件

ユースケース

国、郵便番号、郵便番号、郵便番号のフィールドを考えてみましょう。 要件は次のとおりです。国が「インド」であるときはいつでも、郵便番号でリクエスト本文を作成する必要があり、国が「Us」であるときはいつでも、郵便番号でリクエスト本文を作成する必要があります。ここでは、国の値に基づいてリクエスト本文を構築する必要があります。このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。カスタム条件に基づいてリクエストの本文を構築できます。

B. 応答のための条件

ユースケース

「国」、「郵便番号」、「郵便番号」のフィールドを考えてみましょう。 要件は次のとおりです。国が「インド」の場合、応答に郵便番号があるかどうかを検証し、国が「米国」であるかどうかを検証する必要があります。応答に郵便番号があるかどうかを検証する必要があります。ここでは、国に基づいて応答を検証する必要があります。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Zspecを使用すると、条件に一致するように応答を検証できます。

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

ユースケース

サインアップフォームのフィールド「ユーザー名」を考慮してください。 有効なユーザー名の基準を定義したとしましょう - 一意でなければなりません - 最小長は9でなければなりません - 特殊文字で始まるべきではありません。 シナリオ 1: デフォルト値を割り当てるユーザー名がこれらの条件を満たしていない場合、要件は条件を満たす自動生成されたユーザー名を割り当てることです。 ここでは、[ユーザー名] フィールドにデフォルト値を割り当てる必要があります。 シナリオ 2: 値を拒否するユーザー名がこれらの基準を満たしていない場合、要件は値を拒否することです。 ここでは、要件は、基準を満たしていない値を拒否することです。上記のシナリオでは、値が基準に沿っているかどうかを確認し、デフォルト値を割り当てるか値を拒否して処理する必要があります。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。デフォルト値を割り当てるか、値を拒否することで、条件を満たさない値を処理できます。

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

ユースケース

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

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

ユースケース

すべての従業員に従業員 Id を持つ組織を考えてみましょう。 このフィールドに空の値を許可したくありません。 ここでは、[従業員 id] フィールドの空の値を拒否する必要があります。 このユースケースは、 ZEST 仕様形式ですが、OpenAPI3.0を使用していません。Api のすべてのリクエストと応答で空の値を許可または拒否できます。

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

ユースケース

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

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

ユースケース

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

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

ユースケース

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