アプリケーション、Webサービス、または API間でデータをやり取りする際、ほんのわずかな構造上のエラーがあるだけで、システム全体が機能しなくなる可能性があります。そのため、API統合、データのインポート/エクスポート、アプリケーション設定、マイクロサービス間の通信など、多くのシナリオにおいて、JSONデータの検証は不可欠なステップとなります。4D 21 R3 は、単に Draft 2020-12 へのアップデートにとどまらず、最新の Web および API標準に完全に準拠しています。JSON検証機能はより強力かつ表現力豊かになり、今日の最新ツールと完全に互換性を持つようになりました。
スキーマとは?
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)
// 処理を実行
Else
// エラーを管理
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 の言語に対応できるプラットフォームの一つとしての地位を確立しました。
現在、この投稿へのコメント機能は利用できません。