データ記述のためのJSONスキーマvsデータ検証vs入力検証

Question

JSONスキーマの使用については、有効なデータを記述するタスクを混乱させる（または少なくとも区別しない）格納されたデータ、および入力データの検証を行います。

典型的な例は次のようになります。

var schema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

これは、データストア内の有効なデータがどのように見えるかを記述するためにうまく機能し、それがでますので、それを検証するため（後者はひどく場合に便利-ではありません店舗は既に有効である必要があります）。

var storedData = { 
    id: 123, 
    name: 'orange', 
    description: 'delicious' 
}; 

入力の検証にはうまくいきません。 idは、アプリケーションが生成するために残されている可能性が高く、ユーザーが入力の一部として提供するためではありません。スキーマは、直接入力を検証するものではありません、検証が後にのみ発生する必要があり

var inputData = { 
    name: 'orange', 
    description: 'delicious' 
}; 

ファイン、 1は言うかもしれない、：それは、スキーマを宣言idはrequiredする欠けているため、次の入力が検証に失敗しましたアプリケーションはidを追加し、そのデータは保存されることを意味します。スキーマは、直接入力を検証することを意図していない場合

、しかし、何が1）のJavaScriptの点は、ブラウザで実行されているバリデータ、おそらく直接入力と明らか入力指向readonly 2）点を供給されています仕様のスキーマ機能？

一度設定できるプロパティ（ユーザー名など）と異なるアクセスレベル（たとえば、管理者とオレンジのオーナーがを変更できるようにする必要がある他のユーザーの場合はreadonlyのままにしてください）。

これに対処するためのベストプラクティス（または少なくとも実用的なプラクティス）は何ですか？以下のように、各ユースケースごとに異なるスキーマ？

var baseSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

var ownerUpdateSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: false, readonly: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

var userUpdateSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: false, readonly: true }, 
     name: { type: 'string', required: false, readonly: true }, 
     description: { type: 'string', required: false, readonly: true } 
    } 
}; 

他に何か？

Answer 1

余談：「必須」は今V4で親要素の配列で、「読み取り専用」とは異なり大文字に - 私は私の例については、そのフォームを使用することがあります

私が検証していることに同意します記憶されたデータはかなりまれです。データを記述するだけであれば、 "id"が必要であると指定する必要はありません。

もう1つ言うことは、これらのスキーマにはすべて参照可能なURI（例：/schemas/baseSchema）が必要です。その時点で、あなたはそれらのいくつかで必要な「ID」を作るためにスキーマを拡張することができます

var ownerInputSchema = { 
    type: 'object', 
    properties: { 
     id: {type: 'integer', readOnly: true}, 
     name: {type: 'string'}, 
     description: {type: 'string'} 
    }, 
    required: ['name'] 
}; 

var userInputSchema = { 
    allOf: [{"$ref": "/schemas/inputSchema"}], 
    properties: { 
     name: {readOnly: true} 
    } 
}; 

var storedSchema = { 
    allOf: [{"$ref": "/schemas/inputSchema"}], 
    required: ["id"] 
} 

私は上記の言ったように、けれども、私はstoredSchemaが必要であるべきか分かりません。あなたが終わるのは、データフォーマット（データ所有者によって提供され、編集可能なもの）を記述する1つの "所有者"スキーマであり、追加のプロパティでreadOnlyと宣言するように拡張したセカンダリスキーマがあります。

Answer 2

Json-Schemaの目的は、v4でより明確に定義されていると思います。目標は、データ構造の検証（保存されるかどうか、ワイヤを介して送信されたか、インタラクティブな方法で作成されているか）に役立ちます。

readOnlyは検証制約がないため、Json-Schema検証プロパティではありません。 Json-Schema v4では、readOnlyはハイパースキーマ定義の一部です。 POSTリクエストでこのプロパティを変更できないことを表現するために使用できます。

一時的な「不良」データを許可する場合や、システムにデータを追加する前にエラーを修正する必要がある場合、Json-schemaはユーザーとのやりとりの実装方法を定義しません。これはあなた次第です。