공식 API가 있다면 가장 먼저
검토합니다.
API는 브라우저 화면을 직접 조작하는
방식보다 구조가 명확하고 변경 대응이
쉬운 경우가 많습니다.
인증키, 호출량 제한, 캐시 정책, 실패 응답,
갱신 주기를 확인해 비용과 안정성을
함께 설계합니다.
데이터 제공 방식이 달라도
하나의 화면으로 통합합니다.
서로 다른 API의 필드와 형식을
내부 기준으로 정규화하면
관리자 화면에서는
공급자를 신경 쓰지 않고
같은 방식으로 조회할 수 있습니다.
여러 종목 스포츠 API를 통합 운영하는
베스트픽과 같은 데이터 플랫폼도
이런 구조를 사용합니다.
API가 없는 경우도 대안을
검토할 수 있습니다.
연계 API가 제공되지 않는 서비스는
업무 목적, 이용 조건, 접근 방식에 따라
별도 조회 에이전트나 수동 보완
프로세스를 설계할 수 있습니다.
처음부터 특정 공급 방식에 강하게
묶이지 않도록 모듈을
분리하는 것을 우선합니다.
