JSON Schema 검증기

이 도구는 Ajv 라이브러리를 통해 JSON Schema Draft-07, Draft 2019-09, Draft 2020-12를 지원합니다. 가장 흔한 스키마 기능들이 지원됩니다.

네! JSON Schema는 깊게 중첩된 객체와 배열을 지원합니다. 중첩의 모든 수준에서 properties와 items를 정의할 수 있으며, 각 필드마다 개별 검증 규칙을 둘 수 있습니다.

이 도구는 먼저 스키마 자체가 유효한 JSON Schema인지 검증합니다. 스키마에 오류가 있으면 데이터 검증을 시도하기 전에 그 오류들이 보고됩니다.

type (string, number, object, array, boolean, null), 중첩 스키마를 담는 properties, 필수 키를 나열하는 required, 고정 값 집합을 위한 enum, 정규식 제약 문자열을 위한 pattern, 그리고 범위 검사 minimum/maximum과 minLength/maxLength입니다. additionalProperties: false는 객체를 추가 키에 대해 엄격하게 만듭니다. 이들이 함께 API 검증 규칙의 대부분을 아우릅니다.

현대 JSON Schema에서 format은 기본적으로 주석이지 자동 단정이 아닙니다 - 검증기는 구성된 경우에만 강제하는데, 2020-12 스펙은 이를 별도의 format-assertion 어휘로 명시했습니다. 강제가 보장되어야 한다면 pattern이나 커스텀 키워드를 쓰고, 그 외에는 format을 상호운용성 메타데이터로 다루세요.

#/$defs/address를 가리키는 $ref는 $defs 아래의 스키마 조각을 참조하여 사용되는 곳마다 그것에 대해 검증합니다 - 이것이 중복 제거 메커니즘입니다. Draft 2020-12는 이전 definitions를 $defs로 이름을 바꾸고, 댓글 트리 같은 재귀 구조를 위해 $dynamicRef를 공식화했습니다. 참조는 외부 문서를 가리킬 수도 있지만, 로컬로 번들하는 것이 더 흔합니다.

allOf는 모든 하위 스키마가 유효해야 합니다 - 교집합으로, 기반 스키마에 추가 제약을 합성할 때 씁니다. anyOf는 최소 하나가 필요합니다 - 합집합으로, 다형성 페이로드에 씁니다. oneOf는 정확히 하나가 필요합니다; 두 개 또는 0개의 하위 스키마가 유효하면 실패하는데, 이는 사람들이 예상보다 엄격해서 겹치는 스키마에서 뜻밖의 오류를 일으키는 흔한 원인입니다.

2020-12은 스펙을 개별적으로 활성화 가능한 어휘들로 나누고(validation, annotation, format-assertion), definitions를 $defs로 이름 바꾸고, exclusiveMinimum을 단순 숫자로 단순화하고, 이전 items 키워드를 prefixItems와 items로 대체했습니다. 대부분의 도구는 둘 다 지원합니다; draft-07이 여전히 가장 널리 배포되어 있지만, 2020-12가 현재 공표된 표준입니다.