같은 내용을 다시 보낸 뒤의 변화

상품 수정 인터페이스를 만들면서 모든 필드를 현재 값으로 채워 보내는 것이 안전하다고 봤다. 안 바꿀 항목도 지금 값을 그대로 실으면 어긋날 일이 없을 것 같았다.

Open Table of contents

모든 필드를 채워 보내는 안전

이 방식은 빠뜨린 필드 때문에 값이 지워지는 사고를 막아 준다. 실제로 어떤 인터페이스에서는 생략한 필드가 그대로 유지되고 빈 값을 보내면 지워진다.

그 경험을 그대로 적용하면 전부 채워 보내는 쪽이 방어적이다. 그런데 이 전제가 필드마다 성립하지는 않았다.

질의응답을 뒤지다 상세 내용을 같은 값으로 다시 보내면 편집기로 만든 상세가 직접 입력 모드로 바뀐다는 답변을 봤다. 그리고 그 전환은 되돌릴 수 없었다.

저쪽이 값이 아니라 그 필드가 요청에 들어 있는지를 보고 모드를 정하기 때문이다. 그러면 값을 그대로 실어도 상태가 바뀌므로 생략하는 쪽이 유지가 된다.

앞서 확인한 필드는 생략이 유지이고 빈 값이 제거였는데 이 필드는 포함이 전환이고 생략이 유지였다. 방향이 서로 반대라 일괄 규칙을 만들 수가 없었다.

그래서 필드별로 생략과 빈 값과 동일 값 재전송의 결과를 칸으로 나눈 표를 만들었다. 요청 빌더는 그 표를 보고 필드마다 다르게 채우게 했다.

같은 조사에서 조회 인터페이스에 한 번에 받을 수 있는 건수 상한이 있다는 것도 확인했다. 초과분은 응답에 담겨 오는 이어받기 값을 다음 호출에 넣어야 받아진다.

개발 중에는 데이터가 적어 상한에 안 걸리므로 구현하지 않아도 통과한다. 운영에서 데이터가 쌓인 어느 날 초과분이 조용히 잘리므로 반드시 구현해야 하는 종류였다.

문서의 필수 표기가 스키마 필수만 나타내고 다른 필드 값에 따라 필요해지는 조건부 필수는 안 적혀 있다는 것도 확인했다. 등록 상품이 하나도 없으면 토큰 발급 자체가 거부된다는 것도 답변에만 있었다.

마지막으로 아예 제공되지 않는 기능을 목록으로 정리했는데 송장 수정과 주소 등록과 이력 조회 같은 것들이었다. 이 목록을 기획 단계에 넣지 않으면 만들다가 없다는 것을 알고 이미 만든 것을 뜯게 된다.