JSONの検証を簡素化し、堅牢性を高める

アプリケーション、Webサービス、またはAPI間でデータをやり取りする際、ほんのわずかな構造上のエラーでも、システム全体が機能しなくなる可能性があります。 そのため、API統合、データのインポート/エクスポート、アプリケーションの設定、マイクロサービス間の通信など、多くのシナリオにおいて、JSONデータの検証は不可欠なステップとなります。4D 21 R3は、単にDraft 2020-12へのアップデートにとどまらず、最新のWebおよびAPI標準に完全に準拠しています。JSON検証機能はより強力かつ表現力豊かになり、今日のツールと完全に互換性を持つようになりました。

HDI: Json Validate

スキーマとは何ですか？

JSONスキーマを使用すると、ドキュメントの期待される構造（データ型、必須フィールド、許容値、および形式（メールアドレス、URLなど））を正確に記述できます。

このスキーマのおかげで、検証コードを手動で記述することなく、データ交換の品質と信頼性を保証できます。受信したJSONが定義されたルールに準拠していない場合、4Dは検証がどこで、なぜ失敗したかを正確に通知します。

これにより、大幅な時間の節約、アプリケーションのセキュリティ強化、そして堅牢なインターフェースや信頼性の高いWebサービスの設計に向けた強固な基盤が提供されます。

4D には、JSON オブジェクトを JSON Schema 標準に準拠したスキーマと比較するための `JSON Validate ` コマンドが用意されています。 4D 21 R3 では、このコマンドが大幅に進化しました。最新の標準（Draft 2020-12）に対応し、柔軟性の向上、新しいキーワード（const、if/then/else、unevaluatedProperties など）、4D ネイティブの日付検証、および最新のツールとの相互運用性の向上を実現しています。

例：条件付きルールの使用

新しいJSON Schema標準では強力な条件付きルールが導入され、ビジネスロジックの一部をスキーマに直接エンコードできるようになりました。これはDraft-04では煩雑であったり、不可能であったりしたことです。

典型的な例として、選択された支払い方法に応じて支払いを検証する場合を考えてみましょう。支払い方法に応じて：

• クレジットカードの場合、「cardNumber」と「expiryDate」の指定が必須、
• 銀行振込の場合は、「iban」と「bic」が必須となり、
• それ以外（例えば現金払い）の場合は、これらのフィールドはいずれも必須ではありません。

Draft-04では、これらのチェックをすべて4Dコード内で手動で実装する必要がありました。スキーマでは型、基本的な制約、必須フィールドのみを定義できましたが、「paymentMethod = credit_card の場合、cardNumber と expiryDate を必須とする」といった条件付きロジックを表現することはできませんでした。

Draft-2020-12 では、すべてが変わりました。これらの条件付きルールを JSON Schema 内で直接定義できるようになりました。具体的な例を以下に示します：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Order Schema",
  "type": "object",
  "properties": {
    "orderId": { "type": "integer" },
    "customer": { "type": "string" },
    "amount": { "type": "number", "minimum": 0 },
    "paymentMethod": {
      "type": "string",
      "enum": ["credit_card", "bank_transfer", "cash"]
    },
    "cardNumber": { "type": "string", "pattern": "^[0-9]{16}$" },
    "expiryDate": { "type": "string", "pattern": "^(0[1-9]|1[0-2])/[0-9]{2}$" },
    "iban": { "type": "string" },
    "bic": { "type": "string" },
  },
  "required": ["orderId", "customer", "amount", "paymentMethod"],

  "if": { "properties": { "paymentMethod": { "const": "credit_card" } } },
  "then": { "required": ["cardNumber", "expiryDate"] },
  "else": {
    "if": { "properties": { "paymentMethod": { "const": "bank_transfer" } } },
    "then": { "required": ["iban", "bic"] }
  }
}

このスキーマでは、

• 数値の形式を制御するための正規表現（パターン）；
• 支払いタイプに応じて必須フィールドを適応させるための条件付きルール（if/then/else）。

次に、4D側でレスポンスを検証します:

var $response; $schema; $result : Object
$response := JSON Parse($json; *)
$schema := JSON Parse($jsonSchema)
$result := JSON Validate($response; $schema)

If ($result.success)
  // your treatment
Else
  // manage errors
End if

組み込みの検証機能のおかげで、4Dコードはシンプルに保たれます。支払い方法に基づいて条件を手動でテストする必要はありません。

スキーマは、バックエンドチーム、フロントエンド、さらにはサードパーティのパートナー間でも共有できる、真の機能仕様書となります。

互換性

各 JSON スキーマは、$schema 属性を通じて使用する標準を指定します。

4D では、2 つの JSON Schema パーサーのみがサポートされています。

• Draft-04
• Draft 2020-12

選択されるパーサーは、JSONスキーマドキュメント内の$schemaプロパティの値によってのみ決定されます。

例：

• Draft-04を使用する場合:

"$schema": "http://json-schema.org/draft-04/schema#"

• Draft 2020-12を使用する場合：

"$schema": "https://json-schema.org/draft/2020-12/schema"

つまり、Draft-04 に基づく既存のスキーマは引き続き問題なく動作し、一方で新しいバージョンを自分のペースで採用する自由も確保されます。

$schema属性が指定されていない場合、4DはデフォルトでDraft-04を使用します。ただし、使用する標準を指定することを強く推奨します。REST APIからのレスポンスを検証するため、またはAIにレスポンス形式を説明するためにスキーマを共有する場合、相手がどのバージョンのスキーマを使用しているかを知る必要があります。

主なポイント

4D 21 R3では、JSON Validateコマンドが最新のJSON検証標準に準拠し、AI APIやその他のWebサービスから送信されるデータの検証が可能になりました。これにより、以下のメリットが得られます：

• 最新のJSON Schema標準への対応、
• より強力な新キーワード、
• 業界標準ツールとの互換性の向上、
• 既存のスキーマとの互換性を維持しつつ。

4Dプロジェクト内で「JSON Validate」とAPI呼び出しを組み合わせることで、追加の作業を必要とせずに、AI統合の信頼性を高め、データフローの安全性を確保できます。このアップデートにより、4Dは最新のAPI、マイクロサービス、生成AIの言語に対応できるプラットフォームの一つとしての地位を確立しました。