1

スキーマでは、次のコンステレーションのみを許可する必要があります{"status":"nok"}。キーは常に「ステータス」である必要があり、値は「ok」、「nok」、「inProgress」を許可する必要があります。差異のあるオブジェクトや追加のオブジェクトは許可されません...

私はこれを試しました：

{
"description": "blabla",
"type": "object",
"properties": {
    "status": {
        "type": "string",
        "enum": [
            "ok",
            "inProgress",
            "nok"
        ],
        "required": true,
        "additionalItems": false
    }
},
"required": true,
"additionalProperties": false
}

{"status":"nok","status":"nok"} これは機能しますが、このスキームでは、オーバーヘッドを削減するために、使用しているこの「オブジェクト」コンテナがなくても機能する場合は、同じキーと値のペアを2回送信できます。多分誰かが解決策を知っています、ありがとう

4

1 に答える 1

0

その入力には、より根本的な問題があります。

{"status":"nok","status":"nok"}

主に:その入力は有効な JSON ではありません。RFC 4627のセクション 2.2 では、「オブジェクト内の名前は一意である必要がある」と明示的に述べられています。そしてあなたの場合、そうではありません。

つまり、使用する JSON パーサーは、そのような入力に対してやりたいことが何でもできるということです。JSON API の中には、最初に見つかった値を取得するものもあれば、最後に読み取った値を取得するものもあれば、値を合体させるものもあります。RFC では、これは違法ではありません。

本質的に、そのような入力が与えられた場合、JSON パーサーの出力がどうなるかを保証することはできません。そのため、そのような入力の JSON スキーマ検証も保証できません。

于 2013-01-03T00:36:39.423 に答える