어떤 IPC를 선택하든, 서비스 API를 IDL(Interface Definition Language, 인터페이스 정의 언어)로 정확하게 정의해야 합니다. API 우선 방식으로 서비스를 정의하는 문제는 이미 좋은 자료가 많습니다.2 인터페이스 명세를 작성한 후 클라이언트 개발자와 함께 의논하는 과정을 몇 차례 되풀이하면서 API를 정의한 후 서비스를 구현합니다. 이렇게 선 설계 후 구현 방식으로 진행하면 클라이언트 니즈에 좀 더 부합한 서비스를 구축할 수 있습니다.
Note≡ 반드시 API를 먼저 설계하라
필자는 아주 작은 프로젝트에서도 컴포넌트가 API에 부합하지 않아 곤란했던 적이 많습니다. 백엔드 자바 개발자와 앵귤러JS 프런트엔드 개발자가 둘 다 자기들은 개발이 끝났다고 주장하는데, 막상 애플리케이션을 돌려 보면 전혀 작동되지 않았죠. 프런트엔드와 백엔드가 서로 통신하는 REST 및 웹 소켓 API를 대충 정의했기 때문입니다!
API는 어떤 IPC를 사용하느냐에 따라 그 내용이 결정됩니다. 메시징으로 통신하는 API는 메시지 채널, 메시지 타입, 메시지 포맷으로 정의합니다. HTTP로 통신하는 API는 URL, HTTP 동사, 요청/응답 포맷으로 구성되겠죠(API를 정의하는 방법은 이 장 뒷부분에서 설명합니다).
서비스 API가 고정불변인 경우는 거의 없고 시간에 따라 조금씩 발전합니다. 다음은 API를 발전시키는 방법과 그 과정에서 맞닥뜨리게 될 이슈를 알아봅시다.