2013-02-24 1 views
7

JSON 스키마를 사용할 때 찾을 수있는 점은 유효한 데이터를 설명하는 작업이 혼란 스럽거나 (또는 ​​최소한 구별이 부족한 것 같습니다) 저장된 데이터 및 유효성을 검사하는 입력 데이터. 같은데이터 설명을위한 JSON 스키마 vs 데이터 유효성 확인 v 입력 유효성 확인

전형적인 예를 보이는 :이 데이터 저장소에 유효한 데이터가 유효성을 확인하는, 따라서 같이하고해야하는지 설명하기 위해 잘 작동

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' 
}; 

좋아, 하나 말할 수도, : 그것은 스키마 선언 idrequired 수 없기 때문에 다음 입력 유효성 검사 실패 응용 프로그램은 id을 추가했으며 데이터는 저장 될 내용입니다.

스키마가 직접 입력의 유효성을 검사하는 것이 아니라면 1) 브라우저에서 실행중인 JavaScript 유효성 검사기의 포인트는 아마도 직접 입력을 먹고 2) 명백하게 입력 지향적 인 readonly 사양의 스키마 기능은 무엇입니까?

한 번만 설정할 수 있지만 업데이트 할 수없는 속성 (사용자 이름 등)은 물론 다른 액세스 수준 (예 : 오렌지색의 관리자 및 소유자가 description을 변경할 수 있어야합니다. 다른 사용자는 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 } 
    } 
}; 

다른 건요?

답변

1

사이드 노트 : "필수"지금 V4에서 부모 요소의 배열이며, "readOnly 인은"다른 대문자 - 내 예는 그 양식을 사용하게 될

내가 확인하는 것에 동의 저장된 데이터는 매우 드뭅니다. 데이터를 설명하는 경우 "id"가 필요하다는 것을 지정할 필요가 없습니다.

또 다른 말은이 스키마는 모두 참조 할 수있는 URI가 있어야한다는 것입니다 (예 : /schemas/baseSchema). 제가 위에서 말했듯이, 나는 storedSchema이 필요합니다 확실하지 않다,하지만

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"] 
} 

: 그 시점에서, 당신은 그들 중 일부에서 요구되는 "ID"를 만들기 위해 스키마를 확장 할 수 있습니다. 마지막으로 데이터 형식을 설명하고 데이터 소유자가 편집 할 수있는 하나의 "소유자"스키마가 있으며 추가 속성에 readOnly을 선언하도록 확장 한 보조 스키마가 있습니다.

+0

"데이터를 설명하는 것"이라면 ID가 필요하다는 것을 지정하는 것이 매우 유용합니다. 귀하의 데이터를 소비하는 경우, 나는이 필드에 의존 할 수 있다는 것을 알고, 그렇지 않으면 식별자로 사용할 다른 것을 찾아야합니다. –

0

음, Json-Schema의 목적이 v4에서보다 명확하게 정의되어 있다고 생각합니다.목표는 데이터 구조 유효성 검증 (저장 여부, 전선을 통해 사용자에게 전송되었는지, 대화식 방식으로 작성 중인지 여부)을 지원하는 것입니다.

읽기 전용은 유효성 검증 제한 조건이 없기 때문에 Json-Schema 유효성 검증 특성이 아닙니다. Json-Schema v4에서 readOnly는 하이퍼 스키마 정의의 일부입니다. POST 요청에서이 특성을 변경할 수 없다는 것을 나타내는 데 사용할 수 있습니다.

Json-schema는 임시 "잘못된"데이터를 허용하는 경우 또는 사용자가 시스템에 데이터를 추가하기 전에 오류를 수정해야하는 경우 사용자 상호 작용을 구현하는 방법을 정의하지 않습니다. 이것은 당신에게 달려 있습니다.