서비스의 API는 시간이 지남에 따라 예외없이 변한다. Monolithic 어플리케이션에서는 일반적으로 API를 변경하고 모든 호출자들을 업데이트하는 것이 쉽다. Microservice 기반 어플리케이션에서는 매우 더 어렵다. 심지어 여러분의 API를 호출하는 모두가 동일 어플리케이션의 다른 서비스들일지라도 쉽지 않다. 일반적으로 모든 client가 서비스에 발맞추어 업그레이드하도록 강제할 수 없다. 또한, 여러분은 아마도 이전 버전의 서비스와 새로운 버전의 서비스가 모두 동시에 돌아가고 있는 상황에서 신규 서비스를 배포하는 경우가 증가할 것이다. 이러한 이슈들을 다루기 위한 전략을 가지고 있는 것이 중요하다.

API 변경을 어떻게 다루는지는 변경의 크기에 달려 있다. 어떤 변경 사항들은 작고, 이전 버전과 호환성을 갖는다. 예를 들어, 여러분이 요청이나 응답에 속성을 추가하려고 할지도 모른다. Client나 service를 디자인하여 robustness principle을 보고 아는 것은 좋다.

(robustness principle : 내가 하는 것은 보수적으로, 상대방의 것을 받아들일 때는 자유롭게)

오래된 API를 사용하는 Client는 서비스의 새로운 버전으로도 잘 동작할 것이다. 서비스는 추가된 속성을 빠뜨린 요청에 대해서 기본값을 보내고, Client는 추가된 응답 속성들은 무시할 것이다. 여러분의 API를 쉽게 발전시키기 위해서 IPC 메커니즘과 messaging format을 사용하는 것은 중요하다.

그러나, 때로는 중요하고 호환 불가능하게 API를 변경해야만 할때도 있다. Client들에게 즉시 업그레이드하도록 강제할 수 없기 때문에 서비스는 어느 일정 기간 동안 이전 버전의 API를 지원해야만 한다. 만약 REST와 같은 HTTP기반 메커니즘을 사용했다면, 한가지 접근 방법은 URL에 버전 숫자를 포함시키는 것이다. 각 서비스 인스턴스는 동시에 여러 가지 버전을 처리할 것이다. 그렇지 않으면 각각의 인스턴스에서 특정 버전을 처리하도록 서로 다른 인스턴스에 배포할 수도 있다.