API의 마지막 페이지를 누락하면 전체 거래 건수를 어떻게 검증하나

발행

API에서 거래자료를 한 번 받아 파일로 저장했다고 해서 전체 결과를 받았다고 볼 수는 없다. 응답이 여러 페이지로 나뉘면 첫 페이지의 행 수는 전체 거래 건수가 아니다. 집계를 시작하기 전에 수집이 어디까지 끝났는지 확인하는 절차가 필요하다.

페이지를 넘기는 규칙은 API마다 다르다

Microsoft Graph의 공식 문서는 다음 결과가 있으면 @odata.nextLink를 반환하고, 더 이상 그 값이 없을 때까지 따라가도록 설명한다. 다른 서비스는 페이지 번호와 크기, 전체 건수나 커서 등을 사용할 수 있다. 이 문서의 필드 이름을 국내 부동산 API에도 그대로 있다고 가정하지 않는다. 실제 사용하는 API의 명세에서 다음 페이지와 종료 조건을 먼저 찾는다.

작게 나누어진 가상 결과를 검산한다

가상으로 전체 230건을 페이지당 100건씩 받는 서비스라면 마지막 30건까지 확인해야 한다. 첫 두 페이지만 받은 200건을 전체 거래량이라고 쓰면 30건이 빠진다. 반대로 페이지 재요청이나 갱신으로 같은 거래를 다시 받으면 누락과 중복이 동시에 생길 수도 있다. 원자료의 식별자와 정정 규칙을 확인하고 수집한 행 수와 서로 다른 거래 ID 수를 분리해 점검한다.

완료와 실패를 로그로 구분한다

요청 조건, 수집 시각, 페이지별 응답 건수와 다음 페이지 상태, 오류·재시도 기록을 보관한다. 조회 기간이 같은지, 수집 도중 데이터가 갱신되지 않았는지도 검토한다. 전체 건수가 제공되지 않는 API라면 존재하지 않는 totalCount를 만들어 비교하지 않는다. 명세의 종료 신호와 표본 대조 등 가능한 검증을 사용한다. 이 글은 수집 방법 설명이며 실제 API를 새로 호출하거나 거래 건수를 확인한 보고가 아니다. 파일이 만들어졌다는 사실과 수집이 완료됐다는 사실을 구별해야 통계 해석의 전제가 맞는다.

Graph의 예에서는 다음 링크에서 토큰만 뽑아 새 주소를 조립하지 않고 반환된 전체 URL을 따른다. 실제 API가 다른 방식을 쓰면 그 명세의 규칙을 적용한다. 페이지별 성공 응답이 있어도 마지막 종료 신호가 확인되지 않았다면 수집 상태는 미완료로 둔다.

출처와 확인일