Page History

...

API를 구현관점이 아닌 관계관점에서 그것을 개선하기위해 이해를 해야하는 PM/기획 비개발 영역에도 도움이 될것으로 보여집니다.

공개호스트 - OpenHostService

...

언제 무엇을 받게될지 상류(Upstream) 공급자(UpstreamProvider)가 주로 결정을 하지고 이것을 이용하는 제공받는 하류(DownStream)은 팀은 

상류 스트림을 준수합니다.  하지만 하류팀의 요구를 요구사항을 받아들이기도합니다.

자사의 모빌리티 다양한 운행 이용기록을 챗봇을 통해 표현하고 이것을 이용하고자 할때

외부 챗봇개발팀은 이용기록 버티컬팀에게 기능을 개선하거나 요청할수가 챗봇개발팀은 이용기록을 제공하는 다양한 버티컬팀의 기능을 이용하지만 때때로 개선을 요청할수도 있습니다.

반부패계층 - AntiCorruption Layer

...

라인의 메시지 발송( OpenAPI,OHS)과 카카오의 발송 API(폐쇄적,UD)를 함께 이용할수 있는API를 제작해야하고 개발팀에 제공한다고 가정해봅시다.

이런경우 상류 API를 이용은 하지만 부패 방지 레이어를 별도로 구성하여 이것을 이용하는팀의 요규사항에 맞게 새로운 모델로 변환할수 있습니다.실제로도 라인 API의경우 OpenAPI에 가깝고 KAKAO API의 경우 비공개로 폐쇄형에 가깝습니다.

파트너쉽

상담기능을 위한 네이버 톡톡 API가 존재하지만 채팅API가 존재하며 그것을 이용하여 채팅시스템을 작성하는 개발팀이 유일하다고 개발하는 유일한 내부팀이 있다고 가정해봅시다.

이 경우 파트너쉽 관계로 함께 성장하거나 함께 망할수 있는 관계로 가장 적극적으로 지원할수 있습니다.

추후 서로의 의존성이 줄어든다고 하면 다른 관계로 맵핑관계가 변경될수 있습니다.

내부가 아닌 외부관계의 예를 추가로 하자면

카카오톡의 알림톡/추가적인 예를 하나를 더 들면 카카오톡의 친구톡 API가 파트너사를 통해 비즈니스 확장이 되었지만, 파트너사를 통해 시장을 이미 확보했기때문에

이 관계를 변경하고 상위업체는 새로운 API관계를 통해 비즈니스 관계를 새롭게 만들수 있습니다.

파트너쉽은 언제든 이익관계또는 아키텍처의 의존관계에 의해 깨지거나 변경될수 있다란 의미이며 실제로 일어나고 있는 일입니다.

파트너쉽이 꼭 외부만 적용되는것이 아닌 동일회사 내부팀간에도 적용할수 있으며

CS팀과 그로인해 발생하는 트래픽으로 마케팅을 개발하는팀은  한쪽이 없으면 안되는 관계로 파트너쉽 관계로 표현할수 있습니다.

통해서만 비즈니스 확장을 할수 있습니다. 이 경우도 파트너쉽관계로 표현될수 있으며

내부 파트너쉽의 변경은 주로 아키텍처 변경에의해 발생할수 있지만 이경우는 이익관계에의해 조정되거나 변경될수 있습니다.

API 관계를 맺는 위 요소를 이용하여 복잡하게 이용하는 API의 관계중심의 구성도를 가상의 CS서비스를 중심으로 작성을 시도 해보겠습니다. 이것을 종합하여 다음과같이 가상으로 외부 API를 이용하는 개발서비스와함께 API  맵핑 관계를 그려보겠습니다.

...