데이터 형식·구조화 데이터
필수 항목 누락과 자료형 오류 찾기
사용할 도구
괄호·따옴표가 맞아도 데이터가 거부될 수 있습니다. JSON 문법은 읽을 수 있는지만 보고 count가 숫자인지 name이 있는지는 정하지 않습니다. 스키마는 그 약속을 별도로 적습니다. API로 보내지 않고 작은 예로 확인합니다.
SheepDev는 스키마 키워드 일부를 지원하며 전체 규격 구현은 아닙니다. 예시는 현재 구현의 필수 항목·단일 타입·열거값·수치 범위를 사용합니다. 전체 업무 계약 보증이 아니라 불일치 위치를 찾는 보조로 쓰세요.
정상 데이터·스키마 한 쌍부터 준비
{"name":"Notebook","count":2,"status":"draft"}{
"type": "object",
"required": ["name", "count"],
"properties": {
"name": { "type": "string" },
"count": { "type": "integer", "minimum": 0 },
"status": { "enum": ["draft", "published"] }
}
}이 쌍은 통과합니다. name·count 존재, name 문자열, count 비음수 정수, status 허용값입니다. 정상 기준이 있어야 데이터와 스키마 중 어디가 틀렸는지 나눌 수 있습니다. 이후 스키마를 고정하고 데이터 조건 하나씩 바꾸세요.
properties에 적는 것만으로 필수는 아닙니다
{"name":"Notebook","status":"draft"}count는 required에 있어 빠지면 실패하고 status만 빼면 통과합니다. properties는 있을 때 조건, required는 반드시 있어야 할 항목입니다. 정의한 필드가 빠져도 오류가 없으면 둘을 확인하세요.
필수는 비어 있지 않다는 뜻이 아닙니다. 이 조건은 문자열만 요구하므로 빈 name도 통과합니다. 빈 문자열 금지는 별도 조건이며 통과가 업무상 유효한 이름 보장은 아닙니다.
2·"2"·null은 다른 값
{"name":"Notebook","count":"2","status":"draft"}따옴표 2는 문자열이라 integer에 실패하며 숫자처럼 보여도 강제 변환하지 않습니다. null은 필드는 있어도 정수가 아닙니다. 누락·빈 문자열·null·숫자 0을 구분하세요.
CSV 변환에서 자주 드러납니다. 2처럼 보이는 셀이 JSON 정수가 된다는 보장은 없습니다. 선행 0 ID는 문자열이어야 할 수 있습니다. 통과만 위해 전부 숫자로 바꾸지 말고 항목 의미를 확인하세요.
타입이 맞아도 허용값은 아닐 수 있습니다
{"name":"Notebook","count":-1,"status":"archived"}-1은 정수지만 minimum:0 위반, archived는 enum에 없습니다. 타입만으로 업무 값 범위를 표현하지 못합니다. count 0·status draft로 고치면 두 문제가 해결됩니다. 하나 고쳐 전부 해결됐다고 가정하지 말고 재검증하세요.
enum에 archived를 추가하면 통과해도 수신 측이 처리할지는 별개입니다. 데이터 오류인지 합의 명세 변경인지 확인하고 오류 제거만 위해 계약을 느슨하게 하지 마세요. 생성·소비 측 스키마 버전을 맞춰야 합니다.
이 예는 미지의 필드를 금지하지 않습니다
extra를 추가해도 이 스키마는 금지하지 않습니다. properties는 배타 허용 목록이 아닙니다. SheepDev는 additionalProperties 같은 미지원 키워드를 오류로 냅니다. 전체 계약은 해당 방언·키워드를 지원하는 검증기로 별도 확인하세요.
$schema·$ref·$dynamicRef도 받지 않고 외부 스키마를 가져오지 않습니다. 공식 예를 복사해도 안 될 수 있습니다. 미지원 부분을 빼고 통과한 것을 원래 전체 계약 검증으로 보지 말고 부분 실험과 정식 검증을 나누세요.
통과한 이유와 아직 안 본 조건 기록
성공하면 필수·타입·열거·범위 중 무엇을 확인했는지 남기세요. 인증·ID 실존·재고·항목 간 업무 규칙은 이 예 밖입니다. 스키마 통과가 API 수락 보장은 아니며 사전 확인 한 단계입니다.
정상뿐 아니라 누락·숫자 문자열·null·음수·미정의 상태도 시험에 남기세요. 허용과 거부를 함께 검증하면 변경 시 의도치 않은 완화를 찾습니다. 오류 경로로 데이터·계약 중 무엇을 고칠지 판단하세요.
Schema를 통과했는데 주문이 실패하는 이유
수량이 1 이상의 정수이고 상품 ID가 문자열이어도 판매 중이거나 재고가 있다는 뜻은 아닙니다. 구조 검증과 업무 데이터 대조는 다른 단계입니다. 이 도구는 데이터베이스나 서비스에 조회하지 않으므로 성공이 ID 존재나 주문 가능성을 보장하지 않습니다. 어느 단계가 통과했는지 명확히 하세요.
필수 항목 누락, 숫자의 문자열화, enum 밖의 값 같은 반례를 남기세요. Schema를 바꾼 뒤 이전에 거부한 사례가 통과한다면 의도적으로 완화한 것인지 확인해야 합니다. 오류를 없애려고 required를 빼면 데이터를 고친 것이 아니라 검사를 줄인 것일 수 있습니다. 키워드가 이 구현에서 지원되는지도 확인하고 미지원 조건을 검증 완료로 취급하지 마세요.