WEBBOOK CHAPTER

10년 뒤에도 깨지지 않는 API 설계: 5장. 오류를 RFC 9457 계약으로 만든다

5장. 오류를 RFC 9457 계약으로 만든다

Problem Details의 type, title, status, detail, instance를 사용하되 내부 stack·SQL·비밀을 노출하지 않는다. type URI는 안정된 의미와 해결 문서를 가리키고 extension은 client가 분기할 최소 값만 둔다.

손쉽게 따라 하기

validation·conflict·rate limit 문제 type 세 개를 정의한다. 입력에는 실제 고객·계정·도메인 대신 tenant-demo, example.invalid와 저장소 fixture만 사용한다. 시작 전 기대 결과와 바꾸지 않을 불변식을 한 줄로 적는다.

같은 화면에서 확인할 증거

lab/public/index.html의 공통 FieldPass Evidence Board에서 책 slug durable-api-design, 장 번호 5, run ID를 선택한다. 입력, 판정, 관측값, rollback을 채우고 명령 결과와 같은지 확인한다. 성공 화면만 캡처하지 않고 의도한 실패 하나와 다음 안전 행동을 함께 남긴다.

막혔을 때

모든 오류가 같은 400이면 재시도와 사용자 행동을 분리한다. 원인을 확정하기 전 최근 변경, 환경, 권한, 시간 범위와 실제 오류를 고정한다. 외부 서비스를 반복 호출하지 않고 로컬 fixture로 최소 재현한 뒤 한 변수만 바꾼다. 복구는 process 상태가 아니라 FieldPass 예약·결제·정산의 업무 결과로 선언한다.