WEBBOOK CHAPTER

10년 뒤에도 깨지지 않는 API 설계: 2장. 스타일을 문제에 맞게 고른다

2장. 스타일을 문제에 맞게 고른다

HTTP resource API, command API, gRPC, GraphQL, event와 batch file은 서로 다른 결합과 운영 특성을 가진다. 외부 호환성과 cache가 중요하면 HTTP, 내부 저지연 typed call이면 gRPC처럼 근거를 적고 유행으로 혼합하지 않는다.

손쉽게 따라 하기

조회·명령·실시간 알림에 각 스타일과 포기한 대안을 배정한다. 입력에는 실제 고객·계정·도메인 대신 tenant-demo, example.invalid와 저장소 fixture만 사용한다. 시작 전 기대 결과와 바꾸지 않을 불변식을 한 줄로 적는다.

같은 화면에서 확인할 증거

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

막혔을 때

한 endpoint에서 GraphQL과 임의 action을 섞었다면 계약을 단순화한다. 원인을 확정하기 전 최근 변경, 환경, 권한, 시간 범위와 실제 오류를 고정한다. 외부 서비스를 반복 호출하지 않고 로컬 fixture로 최소 재현한 뒤 한 변수만 바꾼다. 복구는 process 상태가 아니라 FieldPass 예약·결제·정산의 업무 결과로 선언한다.