JSON 스키마 : 나는 물체를 중첩 한 내 JSON 직렬화 된 데이터에서 문자열 유형

Question

에서 개체 유형을 인코딩하는 제약 조건을 나타낸다는 :

{ 
    "A" : { "A1": 1, 
      "A2": 2 }, 
    "B" : { "B1": 3, 
      "B2": 4 } 
} 

인해 내가 영향을 미칠 수 주어진 제약, 나는 구조를 평평하게해야합니다. 즉, 깊이가 1보다 큰 모든 객체는 문자열로 인코딩되어야합니다.

{ 
    "A" : "\{\"A1\": 1, \"A2\": 2\}" 
    "B" : "\{\"B1\": 3, \"B2\": 4\}" 
} 

을 나는 거의 그 구문 규칙에 바인딩하고 JSON Schema이 제약 조건을 표현해야하기 때문에이 그렇게하고 싶은 위의 예에 적용. 나는이 객체들의 타입이 string이거나 object이 될 것입니다.

{ 
    "title": "My Schema", 
    "type": "object", 
    "properties": { 

    "A": { 
     "type": "string vs. object" 
    "B": { 
     "type": "string vs. object" 
} 

Answer 1

는 동의, 중 당신은 object 또는 string 유형을 선택합니다. 나는 JSON Schema documentation을 들여다 보았고, 제약 조건을 필요한만큼 명확하게 표현할 수있는 것을 찾지 못했습니다. 따라서 두 가지 접근법에 대한 짧은 토론이 내 마음에 있습니다.

유형 문자열

JSON 스키마 객체 등 7 개 기본 유형을 정의합니다. 문자열은 단순히 JSON 문자열로 정의됩니다.

문자열이 사건에 적용 할 0 개 이상의 유니 코드 문자

이

의 순서입니다 다음과 같이 RFC 4627는 심지어 캐릭터 라인의 내용 불구하고 JSON 문자열을 정의 제한되어야한다. 문제는 제한 사항을 전달하는 방법입니다. 다른 하위 스키마를 참조하려면 description을 사용합니다. subschema를 정규 표현식으로 인코딩하는 문자열에 대해 pattern을 정의 할 수도 있습니다. 그러나 이것은 매우 오류가 발생하기 쉽고 사람이 읽을 수있는 것이 아닙니다. 그러나 데이터의 스키마 유효성을 검사하는 데 사용할 수 있습니다.

{ 
    "title": "My Schema", 
    "type": "object", 
    "properties": { 

    "A": { 
     "type": "string". 
     "description": "Please refer to http://... for the subschema." 
    }, 
    "B": { 
     "type": "string" 
     "description": "Please refer to http://... for the subschema." 
    } 
} 

이렇게하면 JSON 공급자가 문자열을 해당 속성에 넣어야한다는 것이 분명합니다. 단점은 전체 스키마를 한 번 볼 수 없으며 설명을 검토하고 조회 프로세스에서 성가시다는 것입니다. 결국 형식이 string이지만 object이 하위 스키마에 정의되어 있으면 매우 혼란 스러울 것입니다.

당신이 문자열을 사용하는 모든 단점을 피할 수 있습니다 단순히 유형을 사용하여

유형의 개체입니다. 여기에서의 문제는 실제로 그것이 기술 된 것은 문자열 인코딩이어야한다는 것입니다.

{ 
    "title": "My Schema", 
    "type": "object", 
    "properties": { 

    "A": { 
     "description": "Must be encoded as string", 
     "type": "object", 
     "properties": { "A1": { "type": "string" }, "A2": { "type": "string" } } 
    }, 
    "B": { 
     "description": "Must be encoded as string", 
     "type": "object" 
     "properties": { "A1": { "type": "string" }, "A2": { "type": "string" } } 
    } 
} 

당신은 항상 유형 string를 사용하고 그것을 위해 properties 정의처럼, 뭔가 완전히 가짜 할 수 있지만, 이것은 잘못된 JSON 스키마 될 것입니다.

---

나는 유형 객체 방법을 사용하도록 추천 할 것입니다.문자열 유형을 사용하는 이러한 제약이 있지만 항상 그 뒤의 데이터를 저하시킵니다. 제약 조건은 다른 방법으로 시행 될 수 있습니다. 누가 데이터를 제공하는지, 모든 당사자에게 제약 조건을 전달하고,이 제약 조건과 관련하여 유효하지 않은 데이터를 차단하십시오.

누가 알겠지만,이 제약 조건은 영원히 존재하지 않을 것입니다. 다른 경우에는 스키마를 다시 변경하십시오. 문자열 인코딩 요구 사항을 설명하는 주석 만 삭제하면됩니다.

Answer 2

이미 답변을 선택했음을 알고 있지만 여기서는 직장에서의 원리 만 언급 할 것입니다.

JSON 스키마는 "의미 론적"유효성 검사를 피하려고합니다. 즉, 스칼라 유형 (예 : 문자열 형식 또는 수치 정밀도 적용)의 데이터 유효성 검사를 의미합니다.

이와 같이 문자열 값의 내부 형식을 문서화하려면 "format" 값 (표준에 적합한 값이 없기 때문에 사용자 정의 값)을 사용할 수 있습니다.

... 또는 "media"을 사용할 수 있습니다. 이 스키마 키워드의 값은 문자열 값에 대한 미디어 유형을 지정하는 "type" 속성을 가질 수있는 객체입니다. 그래서 속성과 같이 보일 것입니다 :

{ 
    "type": "string", 
    "media": { 
     "type": "application/json" 
    } 
} 

검사기가 당신의 패턴 화 된 데이터 형식을 기술 의 관점에서하지만, "format"을 무시하도록 허용하고, (심지어 접선 방향으로 언급하지 않은 것) "media"를 사용하여 검증하는 것이 매우 가능성이있다, "media"이 가장 정확한 방법입니다.

(그러나 허용 된 응답 상태로 데이터 제한이 아닌 serialization 메서드로 처리하는 것이 여러면에서보다 훌륭한 해결책입니다.)