마이크로서비스 API 디자인 패턴 (쉬운 통합을 위한 결합도 최적화 전략)

올라프짐머만,미르코스토커,다니엘뤼브？

(OlafZimmermann)
아키텍처의사결정모델링으로박사학위를받은오랜경력의서비스오리엔티드기반설계자다.이스턴스위스응용과학대학교(EasternSwitzerlandUniversityofAppliedSciences)소프트웨어연구소의컨설턴트겸소프트웨어아키텍처교수로서애자일아키텍처,애플리케이션통합,클라우드네이티브,도메인중심설계,서비스지향시스템을중점적으로연구하고있다.이전에는ABB와IBM에서소프트웨어설계자로일하면서전세계의e-비즈니스및엔터프라이즈애플리케이션개발고객을확보했으며,그이전에는시스템및네트워크관리미들웨어를개발했다.TheOpenGroup의저명한(수석/리더)IT아키텍트이며IEEESoftware의〈Insights〉칼럼을공동편집하고있다.웹서비스에대한관점및최초의IBM레드북인『Eclipse』의저자이기도하다.ozimmer.ch와medium.com/olzzio에서블로그를운영한다.

1부.기초와내러티브

01장.애플리케이션프로그래밍인터페이스(API)기초
__로컬API에서원격API로
____분산과원격에대한간략한역사
____원격API:통합을위한프로토콜기반서비스액세스
____API의중요성
__API설계의의사결정드라이버
____API를성공하게하는것
____여러API설계방법
____API설계가어려운이유
____아키텍처적으로중요한요구사항
____개발자경험
__원격API의도메인모델
____커뮤니케이션참가자
____엔드포인트제공동작을설명하는계약
____대화의빌딩블록으로서의메시지
____메시지구조및표현
____API계약
____책전반에서사용되는도메인모델
__요약
__
02장.호반상호보험사례연구
__비즈니스콘텍스트및요구사항
____사용자스토리및요구되는품질
____분석수준도메인모델
__아키텍처개요
____시스템콘텍스트
____애플리케이션아키텍처
__API설계활동
__목표API사양
__요약
__
03장.API의사결정관련사항
__들어가기:의사결정옵션으로서의패턴,의사결정기준으로서의포스
__기본적인API의사결정과패턴
____API가시성
____API통합타입
____API문서화
__API역할과책임에대한의사결정
____엔드포인트의아키텍처역할
____정보보유자역할정제
____동작책임정의
__메시지표현패턴선택하기
____표현엘리먼트의평면구조와중첩구조
____엘리먼트스테레오타입
__중간짚어보기:호반상호보험사례의책임과구조패턴
__API품질거버닝
____API클라이언트의식별및인증
____API사용량에대한미터링및과금
____API클라이언트의과도한API사용방지
____품질목표및페널티의명시적지정
____오류에대한커뮤니케이션
____명시적콘텍스트표현
__API품질개선을위한의사결정
____페이지네이션
____불필요한데이터전송을피하는다른방법
____메시지에서참조된데이터처리
__API진화에대한의사결정
____버전및호환성관리
____버전의도입및폐기를위한전략
__중간짚어보기:호반상호보험사례의품질및진화패턴
__요약
__
__
2부.패턴
__
04장.패턴언어개요
__위치와범위
__패턴:왜그리고어떻게?
__패턴탐색
____구조의구성:범위별패턴찾기
____테마별분류:주제별패턴찾기
____시간차원:설계개선단계따르기
____탐색방법
__기초패턴:API가시성및통합타입
____패턴:프론트엔드통합
____패턴:백엔드통합
____패턴:퍼블릭API
____패턴:커뮤니티API
____패턴:솔루션내부API
____기초패턴요약
__기본구조패턴
____패턴:아토믹파라미터
____패턴:아토믹파라미터리스트
____패턴:파라미터트리
____패턴:파라미터포리스트
____기본구조패턴요약
__요약
__
05장.엔드포인트타입과동작정의
__API역할및책임의소개
____도전과제와요구되는품질
____패턴설명
__엔드포인트역할:서비스세분성
____패턴:처리리소스
____패턴:정보보유자리소스
____패턴:운용데이터보유자
____패턴:마스터데이터보유자
____패턴:참조데이터보유자
____패턴:링크조회리소스
____패턴:데이터전송리소스
__동작책임
____패턴:상태생성동작
____패턴:인출동작
____패턴:상태전이동작
____패턴:계산함수
__요약
__
06장.요청및응답메시지표현설계
__메시지표현설계소개
____메시지표현을설계할때의과제
____6장의패턴
__엘리먼트스테레오타입
____패턴:데이터엘리먼트
____패턴:메타데이터엘리먼트
____패턴:ID엘리먼트
____패턴:링크엘리먼트
__특수목적표현
____패턴:API키
____패턴:오류보고
____패턴:콘텍스트표현
__요약
__
07장.품질을위한메시지설계개선
__API품질개요
____API품질의개선관련도전과제
____7장의패턴
__메시지세분성
____패턴:임베디드엔티티
____패턴:링크된정보보유자
__클라이언트주도메시지콘텐츠또는응답셰이핑
____패턴:페이지네이션
____패턴:위시리스트
____패턴:위시템플릿
__메시지교환최적화(대화효율성)
____패턴:조건부요청
____패턴:요청번들
__요약
__
08장.API진화
__API진화소개
____API를진화시킬때의도전과제
____8장의패턴
__버전관리및호환성관리
____패턴:버전식별자
____패턴:시맨틱버전관리
__수명주기관리보장
____패턴:실험적미리보기
____패턴:공격적폐기
____패턴:제한적수명보장
____패턴:2개의상용버전
__요약
__
09장.API계약문서화및커뮤니케이션
__API문서화개요
____API문서화의도전과제
____9장의패턴
__문서화패턴
____패턴:API설명
____패턴:요금책정플랜
____패턴:사용비율제한
____패턴:서비스수준계약
__요약
__
__
3부.패턴사용의현재와미래
__
10장.실제패턴사례
__스위스모기지분야의대규모비즈니스프로세스통합
____비즈니스콘텍스트및도메인
____기술적과제
____API의역할과현황
____패턴사용및구현
____회고및전망
__건설영역의제안및주문프로세스
____비즈니스콘텍스트및도메인
____기술적과제
____API의역할및현황
____패턴사용및구현
____회고및전망
__요약

__11장.결론
__짧은회고
__API관련연구:패턴,MDSL등으로리팩토링
__API의미래
__추가참고내용
__최종코멘트


부록A.엔드포인트식별및패턴선택가이드
부록B.호반상호보험사례의구현
부록C.마이크로서비스도메인특화언어(MDSL)

◆패턴으로API설계문제파악및극복하기
◆API엔드포인트와동작의적절한크기조정하기
◆요청및응답메시지와그표현설계하기
◆메시지설계품질다루기
◆API진화계획세우기
◆API계약문서화및커뮤니케이션
◆패턴을결합해실제문제를해결하고트레이드오프를올바르게다루기

기술과설계를개선하기위해노력하는중급수준의소프트웨어전문가를대상으로하는책이다.주로플랫폼독립적인아키텍처지식에관심이있는통합아키텍트,API설계자,웹개발자를대상으로패턴을제시한다.백엔드-투-백엔드통합전문가와프론트엔드애플리케이션을지원하는API개발자모두이패턴에담긴지식을활용할수있다.API엔드포인트의세분성과메시지에서교환되는데이터에초점을맞추기때문에API제품책임자,API검토자,클라우드테넌트및프로바이더도도움을받을수있다.
API기본사항에이미익숙하고메시지데이터계약설계및API진화를포함한API설계능력을향상시키고자하는중급소프트웨어엔지니어(개발자,아키텍트또는제품책임자등)를위한책이다.
학생,강사,소프트웨어엔지니어링연구원도이책에소개된패턴과프레젠테이션을유용하게활용할수있다.초보자를위한책을먼저읽지않고도이책과패턴을이해할수있도록API기본사항과API설계를위한도메인모델을소개한다.


인간은다양한언어로의사소통을한다.소프트웨어도마찬가지다.소프트웨어는다양한프로그래밍언어로작성될뿐만아니라수많은프로토콜(예:HTTP)과메시지교환형식(예:JSON)을통해통신한다.누군가가소셜네트워크프로필을업데이트하고,웹상점에서물건을주문하고,신용카드를긁어물건을구매하는등의모든과정에서HTTP,JSON및기타기술이작동한다.
●스마트폰의모바일앱과같은애플리케이션프론트엔드는온라인상점의구매주문과같은백엔드에트랜잭션처리를요청한다.
●애플리케이션파트는고객프로필이나제품카탈로그와같이수명이긴데이터를서로,그리고비즈니스파트너,고객,프로바이더의시스템과교환한다.
이러한시나리오에관련된크고작은소프트웨어컴포넌트는최종사용자에게공동으로서비스를제공하면서각자의목표를달성하기위해다른컴포넌트와대화한다.이러한배포문제에대한소프트웨어엔지니어의대응책은애플리케이션프로그래밍인터페이스(API)를통한애플리케이션통합이다.모든통합시나리오에는최소한2명의커뮤니케이션당사자,API클라이언트와API프로바이더가포함된다.API클라이언트는API프로바이더가노출한서비스를소비한다.API문서는클라이언트-프로바이더상호작용을관리한다.
인간과마찬가지로소프트웨어컴포넌트도의사소통할때서로를이해하는데어려움을겪는경우가많으며,설계자가메시지콘텐츠의적절한크기와구조를결정하고가장적합한대화스타일에합의하기가어렵다.어느쪽도자신의필요를표현하거나요청에응답할때너무조용하거나지나치게말이많은것을원하지않는다.일부애플리케이션통합및API설계는매우잘작동하며,관련당사자들이서로를이해하고목표를달성한다.이들은효과적이고효율적으로상호연동한다.반면에명확성이부족해참여자에게혼란을주거나스트레스를주는경우도있고,장황한메시지와수다스러운대화는커뮤니케이션채널에과부하를일으키고불필요한기술적위험을초래하며개발과운영에추가적인작업을유발할수있다.
그렇다면좋은통합API설계와그렇지않은통합API설계는어떻게구분할까?API설계자는어떻게하면긍정적인클라이언트개발자경험을촉진할수있을까?좋은통합아키텍처와API설계를위한가이드라인은특정기술이나제품에의존하지않는것이이상적이다.기술과제품은왔다가사라지지만관련설계조언은오랫동안관련성을유지해야한다.현실세계로비유하자면키케로의수사학과웅변,로젠버그의‘비폭력대화:일상에서쓰는평화의언어,삶의언어’[Rosenberg2002]와같은원칙을들수있다.이러한원칙은영어나일부언어에만국한된것이아니며,언어가진화하더라도사라지지않을것이다.이책은통합전문가와API설계자를위한유사한툴박스와어휘를구축하는것을목표로한다.이책은다양한통신패러다임과기술에적합한API설계및진화를위한패턴으로지식을제시한다.HTTP및JSON기반웹API를주요예제로사용한다.