API 응답을 비교하고 호환성을 평가하는 방법.
구조 변경과 값 변경을 구분하세요. 예제 값이 바뀌었다고 반드시 API 계약이 깨지는 것은 아니지만 필드 삭제는 중요할 수 있습니다.
작업에 맞게 절차를 조정하세요.
응답 구조와 값을 별도로 비교하며 각 변경의 경로를 보존하세요. 삭제되거나 이름이 바뀐 필드와 예제 값 변경을 구분하고 실제 소비자 요구사항에 따라 호환성을 평가하세요.
- 제공할 내용
- 예제 응답 두 개와 비교 규칙.
- 받을 결과
- 호환성 우려를 포함한 스키마 및 값 변경.
입력과 결과를 확인하세요.
설명용 입력과 출력 · 실제 WebAct 실행이 아닌 학습용 예시
입력 항목 예시개
Compare response field sets. Old: {"id":"A1","name":"Ada"}. New: {"id":"A1","display_name":"Ada"}. No API compatibility contract supplied.완성된 예시
Unchanged field: id. Removed field: name. Added field: display_name. Potential impact: clients reading name may fail or lose displayed text. A rename is plausible, but the samples alone do not prove semantic equivalence or the full compatibility policy.
이 입력을 프롬프트에 넣고 WebAct에 복사해 작업을 실행해 보세요. 결과는 설명용 예시와 다를 수 있습니다.
판단 기준과 문제 해결.
예제 값이 바뀌면 자동으로 API 계약이 깨지나요?
아니요. 값은 정상적으로 달라질 수 있습니다. 스키마, 의미, 소비자의 가정이 변경의 중요성을 결정합니다.
이름이 바뀐 필드가 무관한 삭제와 추가로 나타나는 이유는 무엇인가요?
구조 비교로 의도를 증명할 수는 없습니다. 이름 변경 가능성을 표시하고 문서화된 변경 및 소비자 사용 방식과 대조해 확인하세요.
직접 준비한 자료로 시도하세요.
작업 프롬프트의 예시를 내 자료로 바꾸세요. 필요한 요구 사항은 유지하고 작업을 WebAct에 복사하세요.
작업 맞춤 설정 및 복사 ↑