Top

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

  • 원서명Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges (ISBN 9780137670109)
  • 지은이올라프 짐머만(Olaf Zimmermann), 미르코 스토커(Mirko Stocker), 다니엘 뤼브케(Daniel Lübke), 우베 즈둔(Uwe Zdun), 세자레 파우타소(Cesare Pautasso)
  • 옮긴이이승범
  • ISBN : 9791161759241
  • 44,000원
  • 2024년 11월 14일 펴냄
  • 페이퍼백 | 664쪽 | 188*235mm
  • 시리즈 : 소프트웨어 아키텍처

책 소개

요약

마이크로서비스의 API를 설계할 때 참고할 수 있는 패턴들을 소개하는 책이다. 이 패턴은 입증되고 재사용 가능한 솔루션 엘리먼트를 통해 API 설계 및 발전의 복잡성을 극복하는 데 도움을 주는 것을 목표로 패턴 커뮤니티는 피드백 프로세스를 통해 정립된 내용을 소개한다. HTTP, 웹 API, 서비스 지향 아키텍처를 포함한 일반적인 통합 아키텍처에 적용 가능한 패턴뿐 아니라, 개별 API 엔드포인트와 메시지 교환과 관련된 패턴 그리고 API의 진화와 관련된 패턴도 소개한다. 이러한 패턴들은 프로그램 내부 API가 아닌 원격 API(remote API)에 초점을 맞춰 클라이언트 측과 프로바이더 측 모두에서 개발자 경험을 개선하는 것을 목표로 한다.

추천의 글

“API가 세상을 집어 삼키고 있다. 조직 내부 그리고 외부와의 협업에서도 API에 더 많이 의존하게 된다. 이러한 API를 설계할 때 패턴을 사용하는 것은 설계에서 요구되는 도전적 과제를 해결하는 데 큰 도움이 된다. 이 책은 실무자가 API를 좀 더 효과적으로 설계할 수 있게 돕는다. 즉, 표준 설계 문제는 패턴으로 해결해서 실무자는 애플리케이션 도메인 설계에 집중할 수 있게 된다. API 분야에서 일하고 있다면 이 책을 통해 API를 설계하는 방법과 API를 바라보는 시각이 달라질 것이다.”

─ 에릭 와일드(Erik Wilde)/,
Axway의 카탈리스트

“저자들은 정의부터 설계에 이르기까지 API 수명주기 전반에 걸쳐 접근하기 쉬운 방식으로 설계 패턴을 포착했다. 수십 개의 웹 API를 설계한 경험이 있든 이제 막 시작한 초보이더라도 이 책은 일관성을 유지하고 직면할 수 있는 모든 설계 과제를 극복하게 가이드한다. 이 책을 강력히 추천한다!”

─ 제임스 히긴보텀(James Higginbotham)/
『웹 API 설계 원칙』(에이콘, 2023)의 저자이자 LaunchAny의 수석 API 컨설턴트

“API는 오늘날 모든 소프트웨어 개발 환경에 존재한다. API 설계는 쉬워 보이지만 제대로 설계되지 않은 API를 사용해 본 사람이라면 누구나 알 수 있듯이 숙달하기 어려운 기술이며 처음에 보이는 것보다 훨씬 더 미묘하고 복잡하다. 저자들은 오랜 경험과 다년간의 연구 작업을 통해 API 설계에 대한 체계적인 지식을 제공한다. 이 책은 훌륭한 API를 만드는 데 필요한 기본 개념과 실용적인 패턴을 제공해 이를 이해하는 데 도움이 될 것이다. 최신 소프트웨어 시스템의 설계, 구축 또는 테스트에 관여하는 모든 사람에게 추천한다.”

─ 오언 우즈(Eoin Woods)/
Endava의 CTO

“애플리케이션 프로그래밍 인터페이스(API)는 시스템 설계, 특히 소프트웨어 생태계를 점점 더 지배하고 있는 분산 시스템과 관련된 많은 트레이드오프를 관리하는데 도움이 되는 최우선 요소 중 하나다. 이 책은 실무 엔지니어와 소프트웨어 엔지니어링 및 아키텍처 설계를 처음 시작하는 사람 모두가 이해할 수 있게 설명하고 있어 API를 이해하고 설계하는 데 따르는 복잡성을 제거해준다. 시스템 설계에서 핵심적인 역할을 하고자 하는 모든 사람은 이 책에 제시된 API 설계 개념과 패턴을 이해해야 한다.”

─ 이펙 오즈카야(Ipek Ozkaya)/
카네기멜론대학교 소프트웨어 공학 연구소,
엔지니어링 인텔리전스 소프트웨어 시스템 소프트웨어 솔루션 부서 기술 이사,
2019─2023 IEEE Software Magazine 편집장

“나는 API 우선 설계가 대규모의 복잡한 시스템에서 지배적인 설계 형태가 되는 시대로 접어들고 있다고 믿는다. 이러한 이유로 이 책은 시의적절하며 모든 아키텍트가 반드시 읽어야 할 필독서다.”

─ 릭 카즈만(Rick Kazman)/
하와이대학교

“드디어 API 설계라는 중요한 주제를 체계적으로 다루고 있다. 이 훌륭한 패턴 모음이 몇 년 만 더 일찍 있었으면 좋았을 텐데 하는 아쉬움이 남는다.”

─ 게르노트 스타크 박사(Dr. Gernot Starke)/
INNOQ 펠로우

“나는 프로그래머들이 미들웨어의 숨겨진 분산 시스템의 특성을 가볍게 보고 실패하는 소프트웨어 프로젝트들을 봐왔다. 원격에서 실행되지만 문제가 많은 비분산형 시스템에 적절한 API를 설계했기 때문이다. 이 책은 상호 의존적인 세상에서 소프트웨어의 필수적인 분산을 수용하고, 분리된 부분 간의 인터페이스 설계에 대한 시대를 초월한 조언을 제공한다. 패턴은 특정 미들웨어 기술을 넘어 현재와 미래에 성장하는 상호 연결된 소프트웨어 시스템의 생성 및 이해뿐만 아니라 필요한 진화에도 도움이 될 것이다. 이러한 시스템은 글로벌 시장을 목표로 하는 비즈니스를 위해 전 세계에 배포돼 있을 뿐만 아니라 자동차, 주택 그리고 우리 일상에 적용되는 거의 모든 기술에서도 작동한다.”

─ 피터 소메라드(Peter Sommerlad)/
독립 컨설턴트, 『패턴 지향 소프트웨어 아키텍처』(지앤선, 2008)의 저자

“소프트웨어 엔지니어와 아키텍트가 API를 설계, 발전, 문서화할 때 사용하는 스위스 군용 칼과 같은 책이다. 이 책에서 특히 마음에 드는 점은 독자에게 패턴을 던져주는 것이 아니라 저자가 현실적인 예제를 사용하고, 실질적인 아키텍처 결정을 지원하며, 사례 연구를 통해 패턴과 결정의 예를 갖고 설명한다는 점이다. 그 결과, 패턴 언어에 대한 접근성이 매우 뛰어나다. 이 책을 사용해 특정 문제에 대한 해결책을 찾거나 전체 장을 탐색해 API 설계와 관련된 문제 및 솔루션 공간에 대한 개요를 얻을 수 있다. 모든 패턴은 잘 만들어지고, 이름이 잘 지어졌으며, 실무자 커뮤니티에서 피어 리뷰를 거쳤다. 정말 즐거운 일이었다.”

─ 우베 반 히쉬 박사(Dr. Uwe van Heesch)/
소프트웨어 아키텍트 및 전 힐사이드 유럽 부사장

“이 포괄적인 API 패턴 모음은 상호 운용 가능한 소프트웨어 시스템을 설계하는 소프트웨어 엔지니어와 아키텍트를 위한 귀중한 리소스다. API 기초에 대한 소개와 수많은 사례 연구 예제는 미래의 소프트웨어 엔지니어를 위한 훌륭한 교재가 될 것이다. 이 책에서 설명하는 많은 패턴은 실제로 매우 유용하며, 미션 크리티컬한 통합 철도 운영 센터 시스템의 API를 설계하는 데 적용됐다.”

─ 안드레이 푸르다(Andrei Furda)/
히타치 레일 STS 오스트레일리아(Hitachi Rail STS Australia)의 선임 소프트웨어 엔지니어

이 책에서 다루는 내용

◆ 패턴으로 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 설계를 위한 가이드라인은 특정 기술이나 제품에 의존하지 않는 것이 이상적이다. 기술과 제품은 왔다가 사라지지만 관련 설계 조언은 오랫동안 관련성을 유지해야 한다. 현실 세계로 비유하자면 키케로의 수사학과 웅변, 로젠버그의 ‘비폭력대화: 일상에서 쓰는 평화의 언어, 삶의 언어’[Rosenberg 2002]와 같은 원칙을 들 수 있다. 이러한 원칙은 영어나 일부 언어에만 국한된 것이 아니며, 언어가 진화하더라도 사라지지 않을 것이다. 이 책은 통합 전문가와 API 설계자를 위한 유사한 툴박스와 어휘를 구축하는 것을 목표로 한다. 이 책은 다양한 통신 패러다임과 기술에 적합한 API 설계 및 진화를 위한 패턴으로 지식을 제시한다. HTTP 및 JSON 기반 웹 API를 주요 예제로 사용한다.

지은이 소개

올라프 짐머만(Olaf Zimmermann)

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

미르코 스토커(Mirko Stocker)

프론트엔드 개발과 백엔드 개발 중 어느 쪽을 더 좋아하는지 결정하지 못해 중간에 머물다가 API에도 흥미로운 도전 과제가 많다는 것을 알게 된 프로그래머다. 법률 기술 분야에서 2개의 스타트업을 공동 창업했으며, 그중 한 곳에서는 여전히 대표를 맡고 있다. 이러한 과정을 통해 이스턴 스위스 응용과학대학교의 소프트웨어 공학 교수가 돼 프로그래밍 언어, 소프트웨어 아키텍처, 웹 엔지니어링 분야를 연구하고 가르치고 있다.

다니엘 뤼브케(Daniel Lübke)

비즈니스 프로세스 자동화 및 디지털화 프로젝트에 중점을 둔 독립 코딩 및 컨설팅 소프트웨어 아키텍트다. 그의 관심 분야는 솔루션 개발을 위해 본질적으로 API가 필요한 소프트웨어 아키텍처, 비즈니스 프로세스 설계 및 시스템 통합이다. 2007년. 독일 하노버 라이프니츠 대학교에서 박사 학위를 받았으며, 이후 다양한 분야의 산업 프로젝트에 참여했다. 여러 권의 책, 기사 및 연구 논문의 저자이자 편집자이며, 교육을 제공하고, API 및 소프트웨어 아키텍처를 주제로 한 콘퍼런스에서 정기적으로 발표하고 있다.

우베 즈둔(Uwe Zdun)

비엔나 대학교 컴퓨터 과학 학부의 소프트웨어 아키텍처 정교수다. 소프트웨어 설계 및 아키텍처, 경험적 소프트웨어 엔지니어링, 분산 시스템 엔지니어링(마이크로서비스, 서비스기반, 클라우드, API 및 블록체인 기반 시스템), 데브옵스 및 지속적인 배포, 소프트웨어 패턴, 소프트웨어 모델링 및 모델 중심 개발에 중점을 두고 연구하고 있다. 이 분야에서 많은 연구 및 산업 프로젝트에 참여했으며, 전문 저서인 『Remoting Patterns - Foundations of Enterprise, Internet, and Realtime Distributed Object Middleware』(Wiley, 2004), 『Process-Driven SOA - Proven Patterns for Business-IT Alignment』(Auerbach Publications 2011), 『Software-Architektur』(Spektrum Akademischer Verlag, 2008)의 공동 저자이기도 하다.

세자레 파우타소(Cesare Pautasso)

스위스 루가노에 위치한 USI 정보학부 소프트웨어 연구소의 정교수로서 아키텍처, 설계 및 웹 정보 시스템 엔지니어링 연구 그룹을 이끌고 있다. 제25회 유럽 프로그램 패턴 언어 콘퍼런스(EuroPLoP 2022)의 의장을 맡았다. 2004년 취리히공과대학교(ETHZurich)에서 박사 학위를 받은 후 2007년 IBM 취리히 연구소에서 잠시 근무하던 중 운좋게 올라프를 만났다. 『SOA with REST』(Prentice Hall, 2013)를 공동 집필했으며, 『Beautiful APIs』 시리즈, 『RESTful Dictionary』, 『Just Send an Email: Anti-patterns for Email-centric Organizations on LeanPub』을 자체 출판했다.

옮긴이의 말

이 책은 Addison-Wesley 시그니처 시리즈의 여러 책 중 한 권이다. 특히, 아키텍처 설계와 관련해서 관심을 갖다가 알게 됐고 번역 제안을 받아 진행하게 됐다. 쉽지 않은 과정이었지만 몇 가지 알게 된 것, 느낀 것 그리고 번역에 대한 나의 짧은 생각을 적어보려 한다.
반 버논은 도메인 주도 설계(DDD, Domain Driven Design)가 도입되는 데 큰 기여를 하고 있다. 특히, 도메인 주도 설계 구현(IDDD)으로 유명하다. 나는 DDD가 요구 사항과 구현 사이의 간극을 드라마틱하게 줄여주는 실천법이라고 생각한다. 이를 통해 확보한 요구사항의 명확한 이해를 기반으로 효과적인 소프트웨어 설계를 수행할 수 있다. 흥미롭게도 비즈니스 전문가와 개발자들이 함께 일하는 애자일 원칙과도 맞닿아 있다.
또한 이 책은 반 버논 시리즈의 세 번째 번역서다. 하나는 『웹 API 설계 원칙』이다. 반 버논의 추천사를 봐도 두 책의 저자들이 상호 보완적으로 글을 썼다고 한다. 이 책에서는 『웹 API 설계 원칙』의 ADDR 단계 개념을 패턴에 적용하기도 했다. 반 버논의 추천사에서 보면 유기적 구체화(organic refinement)는 소프트웨어와 관련된 모든 개념이 무생물이 생물체의 측면을 ‘특성화’한다는 아이디어를 언급한다. 소프트웨어는 구체적인 시나리오를 통해 모델을 논의하거나 아키텍처를 설계하고 단위 테스트와 도메인 모델을 작성함으로써 살아 움직이기 시작한다. 마찬가지로 건축가이자 패턴 개념을 만든 크리스토퍼 알렉산더는 『Nature of Order』(Center for Environmental Structure, 2002)에서 인간 배아(Embryo)의 예를 들며, 분화(Differentiation)에 대해 얘기한다. 이는 유기적 구체와 매우 유사하며, 유기적이며 발전하고 성장하는 프로세스를 강조한다. 이러한 관점에서 소프트웨어의 진화는 생물의 발전에 대한 이해와 유사한 맥락에서 이해할 수 있다. 생명체가 환경과 상호작용하면서 성장하고 변화하는 것처럼 소프트웨어도 사용자와 시스템 사이의 상호작용 속에서 점진적으로 발전하는 것이라 이해할 수 있다.
여기서 언급하는 패턴의 경우도 이러한 유기적 구체 혹은 분화 과정에서 발견되는 반복적인 내용들을 잡아내 패턴의 커뮤니티에서 키워내고 리뷰해 만들어내는 과정을 거친다. 그러므로 패턴, 유기적 구체, 분화와 같은 것을 이해하고 소프트웨어 구조를 설계할 때 분화의 관점 그리고 소프트웨어가 발전 성장하는 과정에서 패턴을 적용해가는 것이 필요하다는 관점에서 이 책에 접근하는 것을 권한다.
개별 언어는 독특한 여러 특징을 가진다. 이로 인해 각 언어에 내재한 작은 뉘앙스 차이를 다른 언어로 옮기는 일은 매우 어렵다고 생각한다. 이 책에서는 ‘force’라는 어찌 보면 ‘힘’이라고 단순하게 번역할 수 있는 단어의 번역을 오래 고민했다. 소프트웨어 설계에서 ‘force’는 설계 결정에 영향을 미치는 다양한 요인을 의미한다. 특히 이 책에서는 패턴의 문제-해결 쌍과 이후에 상세 설명에서 패턴과 관련된 여러 ‘주요한 요구 사항’을 가리키는 용어로 등장한다. 이는 서로 상충되는 경우가 많다.
이 책에서는 한글과 원어를 여러 번 병기했는데, 그 이유는 소프트웨어 개발이나 소프트웨어 개발과 관련된 도메인의 중심이 여전히 미국에 있기 때문이다. 따라서 영어로 쓴 원서나 관련 논문, 인터넷 글을 읽을 기회가 많으므로 원어 용어에 익숙해져야 한다. 그에 따라 이 책에서도 병기를 충분히 했다. 여러분도 책을 보면서 소프트웨어 아키텍처와 소프트웨어 개발에 관련된 원어 용어에 익숙해졌으면 한다.
번역 중 저자들과의 몇 번의 소통이 있었다. 올라프 짐머만과의 몇 차례 이메일을 통해 사소한 오탈자뿐 아니라 그들이 생각하는 용어 정의와 같은 부분에 대해서도 의견을 나눌 수 있었다. 이러한 과정은 나에게 새로운 경험이었고, 책에 담긴 내용을 좀 더 깊게 이해하는 데 도움이 됐다.

옮긴이 소개

이승범

아일랜드에 있는 더블린시티 대학교(DublinCity University)에서 박사 학위를 받고, 2010년부터 안드로이드 기반 휴대폰 소프트웨어의 멀티미디어 기능 및 서비스 개발 업무를 리드하며 소프트웨어 아키텍트로 활동하고 있다. 소프트웨어 아키텍처, 애자일 방법론(특히 애자일 매니지먼트)에 관심이 많고, 최근에는 ChatGPT와 같은 LLM(Large Language Model)과 연계해 업무 효율화, 전문성 훈련과 같은 개인적 관심뿐 아니라 다른 사람들의 문제 해결, 서비스와 연계 및 아키텍처 설계에 대해 분야를 확대해 가고 있다.

목차

목차
  • 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)

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안