모든 기능적인 조건을 잡아 놓은 후에는 시스템을 마치 잘 정의된 인터페이스와 동작을 갖춘 블랙박스와 같다고 생각하면 되는데, 이 인터페이스는 기본적으로 시스템을 구현한 엔진니어인 우리와 우리 시스템을 사용하는 클라이언트 애플리케이션 간의 계약이다.

이 애플리케이션은 다른 애플리케이션에 의해 호출되기 때문에 이 애플리케이션을 애플리케이션 프로그래밍 인터페이스 줄여서 API라고 한다.

보통 API는 세 개의 그룹으로 분류할 수 있는데 개방형과 내부 비공개와 파트너 API가 있다. 개방은 대중에게 공개되어 있는 것으로 모든 개발자가 사용하거나 본인의 으플리케이션에서 호출 할 수 있으며 일반적으로 개방형 API의 좋은 사례에서는 사용자들로 하여금 우리 측에 요청을 보내고 우리 시스템을 사용하도록 허용하가전 가입하게 만든다.

내부는 우리 회사 내에서만 내부적으로 공개된 API로 다른 팀이나 조직 일부가 활용하는 것이다. 파트너의 경우 개방형과 비슷하나 모든 사람 대신 비지니스 적으로 파트너로 허용된 곳만 사용하도록 하는 것이다.

규모가 큰 시스템 뿐만 아니라 모든 시스템에 좋은 API를 만드는 첫 번째 규칙은 내부 설계와 구현으로부터는 완전히 구별된 채 설계하고 또 우리 시스템을 사용하려는 개발자와 API가 관계가 없도록 둘을 분리하는 것이다.

좋은 API를 설계하기 위해선 작업이 최대한 멱등성을 지니도록 유지하는 것이다. 1회 이상 수행되더라도 추가적인 영향을 끼치지 않는 작업을 의미한다.

예를 들어 사용자 주소를 새 주소로 업데이트 하는 작업은 그 작업을 한 번, 다섯 번, 열 번 몇 번하든 그 결과가 동일한테니 멱등성을 지닌 작업에 해당된다.

반명 잔고에 100달러씩 추가하는 작업은 수행횟수에 따라 결과값이 달라지니 멱등성 있는 작업이 아니다.