ネストされたJSONオブジェクトをYAML Schemaに変換する

ネストされたJSONからYAML Schemaへ

実際のJSONにはほぼ必ずネストされたオブジェクトが含まれます。YAMLスキーマは各ネスト構造を独自のtype: objectと独自のpropertiesブロックとして定義する必要があります。

JSON入力の例

{
  "server": {
    "host": "0.0.0.0",
    "port": 3000,
    "tls": {
      "enabled": true,
      "certPath": "/etc/ssl/cert.pem",
      "keyPath": "/etc/ssl/key.pem"
    }
  },
  "logging": {
    "level": "info",
    "format": "json"
  }
}

生成されるYAML Schema

type: object
properties:
  server:
    type: object
    properties:
      host:
        type: string
      port:
        type: integer
      tls:
        type: object
        properties:
          enabled:
            type: boolean
          certPath:
            type: string
          keyPath:
            type: string
        required:
          - enabled
    required:
      - host
      - port
  logging:
    type: object
    properties:
      level:
        type: string
      format:
        type: string
    required:
      - level
      - format
required:
  - server
  - logging

YAML Schemaでのネストの仕組み

各ネストされたJSONオブジェクトはスキーマツリーに新しいtype: objectノードを導入します。コンバーターはJSONを再帰的に走査し、遭遇するすべてのキーに対してプロパティ定義を作成します。各レベルのrequired配列は存在しなければならないキーを列挙します。

深いネスト戦略

深くネストされた設定（4レベル以上）の場合：

1. $ref定義を使用 -- 再利用可能なサブスキーマをdefinitionsブロックに抽出し、$ref: "#/definitions/TlsConfig"で参照します。
2. 可能な限りフラット化 -- ネストが組織的な目的のみの場合、ドット表記キーによるフラットな構造を検討します。
3. additionalProperties: falseを追加 -- 予期しないキーが検証を通過するのを防ぎます。

$refによるスキーマ構成

definitions:
  TlsConfig:
    type: object
    properties:
      enabled:
        type: boolean
      certPath:
        type: string
      keyPath:
        type: string
    required:
      - enabled

type: object
properties:
  server:
    type: object
    properties:
      tls:
        $ref: "#/definitions/TlsConfig"

このアプローチはスキーマをDRYに保ち、個々のセクションを独立してテスト可能にします。