설명
allOf로 조합한 스키마는 모든 분기의 제약을 함께 적용하며, 뒤의 정의가 앞의 정의를 덮어쓰지 않습니다. 같은 속성 이름을 반복하는 것 자체는 허용되지만, 한 분기는 정수이고 다른 분기는 문자열을 요구하면 그 속성의 값은 두 조건을 동시에 만족할 수 없습니다.
잠재적 영향
속성이 포함된 데이터가 검증에 실패하거나 문서와 생성 모델이 실제 제약을 제대로 표현하지 못할 수 있습니다. 속성이 선택 사항이면 그 속성이 없는 객체는 여전히 유효할 수 있습니다.
해결 방법
동일 속성에 적용되는 모든 타입과 제약을 함께 검토하고 실제 계약에 맞게 충돌을 해결하세요. 호환되는 제약을 추가하는 정상적인 allOf 조합은 유지하고, 이름이 같다는 이유만으로 속성을 바꾸지 마세요.
예시
OpenAPI 3.0 스키마 발췌이며 info와 paths는 생략했습니다. 변경 전의 code 값은 정수와 문자열이어야 하지만 두 타입을 동시에 만족할 수 없습니다. code 자체는 필수가 아닙니다.
변경 전
json
{
"openapi": "3.0.0",
"components": {
"schemas": {
"ErrorModel": {
"type": "object",
"properties": {
"code": {
"type": "integer"
}
},
"allOf": [
{
"type": "object",
"properties": {
"code": {
"type": "string"
}
}
}
]
}
}
}
}
변경 후
json
{
"openapi": "3.0.0",
"components": {
"schemas": {
"ErrorModel": {
"type": "object",
"properties": {
"code": {
"type": "integer"
},
"rootCause": {
"type": "string"
}
}
}
}
}
}
변경 후에는 정수 code와 문자열 rootCause를 별도 속성으로 정의합니다. 실제로 두 필드가 필요한 계약일 때 적절하며, 이름 분리가 모든 중복 제약의 필수 해결책은 아닙니다.