제약이 답변에만 있는 API

외부 인터페이스 클라이언트를 만들면서 공식 문서를 처음부터 끝까지 읽었다. 그것만으로는 부족해서 질의응답 게시판을 뒤졌고 이미 아는 것과 겹치지 않는 항목만 추렸다.

Open Table of contents

문서를 다 읽고도 남은 것

공식 문서는 대체로 무엇을 할 수 있는지를 설명하는 데 지면을 쓴다. 어떻게 하면 왜 안 되는지는 대체로 질의응답 쪽에 흩어져 있었다.

겹치지 않는 것을 추려 보니 네 가지가 나왔고 넷 다 문서에는 없었다. 문서만 보고 만들었으면 넷을 전부 밟았을 것이다.

한도 잔여량을 응답 헤더로 주던 것이 정책 변경으로 더 이상 오지 않는다는 답변이 있었다. 그런데 공식 문서에는 그 헤더에 대한 설명이 그대로 남아 있었다.

그 헤더를 보고 속도를 조절하도록 만든 구현은 그대로 무력해진다. 그래서 상대가 주는 정보에 의존하지 않고 우리 쪽에서 토큰 버킷으로 직접 세는 방식으로 갔다.

한도 체계가 앱 단위와 초당 구간 단위 두 가지로 함께 운영되고 있었다. 구간 단위의 초과는 내 쪽 잔여량이 충분해도 그와 무관하게 발생한다.

내 사용량을 아무리 줄여도 그 구간이 혼잡하면 초과 응답이 온다. 우리 쪽 조절로는 못 피하는 종류이므로 초과 응답을 받았을 때의 처리를 따로 만들어야 했다.

수정 요청에서 필드를 빼면 어떻게 되는지가 필드마다 달랐다. 어떤 필드는 기존 값이 그대로 유지되고 어떤 필드는 빈 값으로 지워졌다.

안 보낸 필드는 안 바뀐다는 가정으로 부분 수정을 하면 다른 값을 지운다. 일괄로 적용되는 규칙이 없으므로 필드별로 확인해 표로 만들어 두는 수밖에 없었다.

변경 내역 조회가 이동식 윈도우라 상태가 바뀔 때마다 기준이 갱신되고 지나친 시점은 다시 조회할 수 없다는 것도 답변에 있었다. 조회 주기를 상태 전이 간격보다 짧게 두어야 한다는 설계 제약이 거기서 나왔다.

넷 다 문서에 없었던 것은 제약이 사고가 나야 드러나고 그때 문서가 아니라 답변에 적히기 때문이다. 각 항목을 요약하지 않고 원문 인용과 함께 남겼는데 문서에 없는 정보는 출처가 유일한 근거이기 때문이다.