스펙과 다른 API에 맞추기

새 거래처 연동을 추가하는데 스펙 문서가 있어서 그대로 짜면 될 것 같았다. 착수 전에 실제로 몇 번 호출해 응답을 받아 봤다.

Open Table of contents

문서와 실제 응답의 타입 차이

문서에는 수량이 정수이고 결제 여부가 불리언으로 적혀 있었다. 실제 응답에서는 둘 다 문자열로 왔다.

정수로 파싱하는 코드를 짰으면 타입 오류가 났거나 언어에 따라 조용히 0이 됐을 것이다. 숫자 필드를 문자열로도 받을 수 있게 파서를 유연하게 만들었다.

존재하지 않는 값을 조회해 보니 문서에 적힌 결과 객체가 아니라 최상위가 빈 배열로 왔다. 구조 자체가 달라서 정상 응답 기준으로 접근하면 오류가 난다.

정상 응답만 보고 짜면 이 형태를 만날 수 없다. 빈 결과의 형태는 빈 결과를 실제로 받아 봐야 알 수 있고 그것을 안 해 본 어댑터는 운영에서 처음 만난다.

인증이 요즘 흔한 서명 방식이 아니라 로그인해서 세션 식별자를 받는 방식이었다. 로그인할 때 접속 주소와 기기 구분 값이 문서에는 선택이었는데 없으면 거부됐다.

세션은 만료되므로 캐싱과 갱신을 넣어야 했다. 유효하면 그대로 쓰고 없거나 만료면 로그인하고 요청 중에 세션 오류가 나면 다시 로그인해 한 번 재시도하게 했다.

새 데이터만 가져오려고 기간 범위 파라미터를 찾았는데 없었다. 있는 것은 최근 며칠이라는 형태뿐이었다.

그러면 며칠치를 받아서 마지막 처리 시각 이후만 우리 쪽에서 거르는 수밖에 없다. 중복이 오지만 상대가 안 해 주는 것은 우리가 하는 것이 어댑터의 몫이다.

별도 시험 환경이 없어서 실제 환경에서만 확인할 수 있었고 호출 한도까지 있었다. 그래서 응답을 파일로 저장해 두고 파싱은 그것으로 반복 시험했다.

실호출은 형태를 확인할 때만 쓰고 한도를 세면서 진행했다. 발견한 특성은 어댑터 파일 상단에 목록으로 남겼는데 이 조사를 앞에서 한 시간이 뒤에서 파서 전체를 다시 쓰는 하루를 아꼈다.