API는 "응용 프로그래밍 인터페이스"(응용 프로그래밍 인터페이스)를 나타냅니다. 대부분의 대기업은 클라이언트용 또는 내부용 API를 어느 단계에서 개발합니다.
금융 플랫폼에 연결된 개방형 API를 통해 귀사는 연결성과 무한한 통합 가능성을 제공할 수 있습니다.
일반적으로 개발자는 사이트, 투자자 포털, 백오피스를 먼저 만들고 API는 나중으로 미룹니다. 사업이 성장하면서 다른 서비스 및 파트너와의 통합 필요성이 생겨납니다. 그러면 개발자는 이러한 통합을 가능하게 하기 위해 API를 추가합니다. API를 모듈 간의 계약이 아니라 나중에 덧붙이는 개선 작업으로 취급할 때 보통 이런 결과가 나옵니다.
이 접근 방식의 약점은 API가 본질적으로 외부 파트너와의 통신을 위해서만 필요한, 플랫폼에 딸린 부속물이라는 점입니다. 그 결과 API 기능은 대체로 빈약하고 백오피스 기능의 일부를 중복해서 담당하게 됩니다.
또한 이런 접근 방식은 취약점을 만들어냅니다. API가 백오피스를 기반으로 만들어졌다면, 백오피스 사이트 자체를 직원만 접근할 수 있도록 하고 외부 요청을 차단할 수 없게 됩니다. 외부 파트너 서비스가 API를 통해 플랫폼에 접근할 수 있어야 하므로, 백오피스 사이트는 직원뿐만 아니라 모두가 접근할 수 있어야 하게 됩니다.
모듈이 처음부터 명시적인 계약으로 정의되기 때문에, API는 나중에 덧붙는 것이 아니라 처음부터 존재합니다. 이는 저희가 아키텍처를 선택하는 방식의 결과이지, 어떤 특정 배포 방식의 결과가 아닙니다.
귀사의 금융 플랫폼에서는 시스템의 "두뇌"가 바로 API라고 할 수 있습니다. 모든 데이터가 API에서 처리되고, 비즈니스 로직이 그 안에 담기며, 데이터베이스와 서비스 제공업체에 대한 요청도 API를 통해 이루어집니다. 귀사의 프로모션 사이트, 고객 포털, 백오피스 역시 모두 API를 통해 플랫폼과 작업합니다.
이러한 접근 방식은 다음과 같은 여러 이점을 제공합니다.
