JSON Schema 검증

로컬 처리
app.schema.view

다음으로도 #data={"name":"Ada"} 또는 #url=... 데이터를 넣을 수 있으며, 읽은 뒤 주소 표시줄에서 지워집니다.

예시 JSON에서 JSON Schema를 추론합니다. 실제 응답이 먼저 있고 나중에 API 문서를 채우거나 검증기의 출발점으로 쓸 때 맞습니다. 추론 결과는 필수 항목과 열거를 사람이 확인하세요. 도구는 「이 예에 무엇이 있는지」만 보고 「업무상 무엇이 있어야 하는지」는 보지 못합니다.

예에서 출발

객체, 배열, 문자열, 숫자는 해당 type으로 매핑됩니다. 중첩 객체는 되도록 properties로 펼칩니다.

빈 배열에 원소 샘플이 없으면 items 타입이 부정확할 수 있으니, 실제 원소 한 줄을 보탠 뒤 추론하세요.

초안으로 쓰기

자동 추론은 「이 필드가 필수인지」를 알 수 없어 required를 직접 고쳐야 합니다. 선택 필드, 열거, format(email, uri)도 사람이 보태야 합니다.

생성 후 ajv 같은 도구로 CI에서 돌리면 구두 약속만 하는 것보다 안정적입니다.

로컬 생성

예시 데이터는 업로드되지 않습니다. 운영 샘플을 쓸 때도 먼저 마스킹하는 것이 좋습니다.

출력에 $schema 선언이 있어 다른 도구가 버전을 식별하기 쉽습니다.

예시

예시 JSON 
{
  "id": 1001,
  "name": "Ada",
  "active": true
}
추론된 Schema(발췌) 
{
  "type": "object",
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "active": { "type": "boolean" }
  }
}
다른 JSON을 검증하는 데 쓸 수 있나요?

이 페이지는 예시에서 Schema를 만드는 데 초점을 둡니다. 생성 결과를 백엔드나 CI의 ajv 같은 도구에 넘겨 검증하세요.

중첩과 배열은요?

되도록 아래로 추론합니다. 빈 배열에 원소 샘플이 없으면 item 타입이 부정확할 수 있습니다.

GraphQL 페이지와 어떻게 고르나요?

REST / JSON 문서에는 Schema를, GraphQL 서비스에는 타입 추론 페이지를 쓰세요.

format: email을 표시하나요?

타입 추론이 중심입니다. 이메일 등 형식은 업무에 맞춰 Schema에 보태세요.

권장 워크플로

  1. 필드가 되도록 갖춰진 성공 응답 샘플을 준비하세요.
  2. Schema를 생성하고 type과 properties가 합리적인지 확인하세요.
  3. required, enum, additionalProperties 같은 제약을 손으로 보태세요.
  4. Mock / CI에서 이후 응답을 검증하고, Diff와 함께 버전 검토를 하세요.

한 예로는 완전한 계약을 끌어낼 수 없습니다. 여러 샘플을 교차 확인한 뒤 Schema를 조이세요.

관련 도구

GraphQL 코드 생성 검증