책 소개
요약
API 목적이 비즈니스 문제의 해결에 있다는 사실을 다시 한번 상기시키는 책이다. 애플리케이션 현대화의 흐름 속에서 비동기화, 마이크로서비스 등 기술적인 관점에만 머무르기 쉬운 관점을 넓혀준다. 또한 비즈니스의 특성을 어떻게 API 설계와 구현으로 풀어낼 것인지, 개발 이후에도 지속되는 변경사항을 효율적으로 API에 반영해 비즈니스 환경 변화에 대응하는 방법론과 절차를 소개하고 있다. 마이크로서비스 아키텍처로 전환하고 현대화된 API 설계를 고심하고 있다면, 이 책의 효과적인 API 설계 방법론과 사례는 좋은 지침이 될 수 있다.
추천의 글
“지난 몇 년 동안 제임스와 함께 일하며 배울 수 있던 것은 내게 행운이었다. 제임스의 실용적인 애플리케이션을 위한 관점과 경험의 깊이에서 오는 다양한 지식은 동료 사이에서도 특별했다. 이제 여러분이 이 책을 통해 더 나은 API를 만드는 방법에 대한 제임스의 강력하고 실용적인 비전을 활용할 기회를 갖게 된 것이 기쁘다. 『웹 API 설계 원칙』은 사용 가능한 기술의 범위를 조사하고 규범적이고 적용하기 쉬운 접근 방식을 제시한다. 이 책의 지침을 적용하는 팀은 고객과 더 잘 소통하고 더 짧은 시간에 더 많은 비즈니스 가치를 제공하며 더 적은 유지 보수가 필요한 API를 만들 것이다. 이 책을 매우 강력하게 추천한다.”
—매튜 레인볼드(Matthew Reinbold)/
포스트맨(Postman)의 API 에코시스템 이사
“제임스는 업계 최고의 API 설계 전문가 중 한 명이며, 이 종합 가이드는 그 사실을 여실히 증명한다. API 설계를 비즈니스 결과 및 디지털 기능의 맥락에서 적용한 이 가이드는 디지털 트랜스포메이션을 겪고 있는 모든 조직에 중요한 지침이 된다.”
—매트 맥라티(Matt McLarty)/
세일즈포스 사 뮬소프트(MuleSoft)의 API 전략 글로벌 리더
“현대 소프트웨어 개발에서 API는 결국 우리가 직면한 많은 문제의 원인이자 해결책이 된다. 개념에서 캐싱에 이르기까지 API를 분해, 분석, 설계하는 제임스의 프로세스는 팀이 생성하는 것보다 더 많은 문제를 해결할 수 있도록 반복 가능한 접근 방식을 제공한다.”
—키이스 케이시(D. Keith Casey, Jr.)/
API Problem Solver, CaseySoftware, LLC
“제임스의 명확하고 따르기 쉬운 가이드에 따라 나는 프로세스를 실제 사용 사례에 적용할 수 있었다. 이를 통해 프로젝트를 수행하는 데 도움이 되는 실용적인 지침, 기술 및 명확한 예를 알게 됐다. API에 연결돼 있고 API로 작업하는 모든 사람에게 권장하는 책이다.”
—조이스 스택(Joyce Stack)/
아키텍트, Elsevier
“이 책은 원칙 그 이상을 보여준다. 독자들은 API를 설계하는 방법인 프로세스를 배우게 될 것이다.”
—아노드 로렛(Arnaud Lauret)/
API Handyman
“이 통찰력 있는 플레이북은 생산적인 협업, 가치 있는 기능 식별 및 모범 사례 작성을 촉진하는 구조화된 프로세스를 통해 API 팀을 안내한다. 제임스는 API 제품을 정의하고 개선하기 위한 실용적인 로드맵으로 수년간의 경험을 정제하고 API 보안, 이벤트, 복원력 및 마이크로서비스 적용에 대한 입문서를 제공한다. API 분야를 처음 접하거나 새로운 팀을 온보딩하고 구조화된 API 정의 프로세스를 도입할 책임이 있는 설계자가 반드시 읽어야 할 책이다.”
—크리스 하다드(Chris Haddad)/
수석 아키텍트(Chief Architect), Karux LLC
이 책에서 다루는 내용
◆ 올바른 설계 프로세스를 통해 훌륭한 API 제공
◆ 개발 팀, 고객, 기타 이해관계자로부터 구체적인 결과에 대한 합의 도출
◆ 작업 스토리 작성, EventStorming 수행 및 기능 모델링
◆ 올바른 API를 식별하고 일관된 API 프로파일로 작업을 구성
◆ 각 프로젝트에 가장 적합한 스타일 선택: REST, gRPC, GraphQL 또는 이벤트 기반 비동기 API
◆ 문서 작성자, 테스터, 고객의 피드백을 바탕으로 디자인 개선
◆ API를 마이크로서비스로 분리
◆ 확장 가능한 설계 및 관리 프로세스를 구현해 API 프로그램 완성
이 책의 대상 독자
인간을 즐겁게 할 단일 API 또는 일련의 API를 설계하려는 모든 사람을 대상으로 한다. 제품 소유자와 제품 관리자는 팀이 API를 설계하는 데 필요한 요소를 더 깊이 이해할 수 있다. 소프트웨어 아키텍트와 개발자는 소프트웨어 아키텍처의 원리를 적용해 API를 설계하는 방법을 배우면 도움이 된다. 테크니컬 라이터는 API 문서의 명확성에 기여할 뿐만 아니라 API 설계 프로세스 전반에 걸쳐 가치를 추가할 수 있는 방법을 식별할 수 있다. 간단히 말해 『웹 API 설계 원칙』은 개발 또는 비개발 역할에 관계없이 API 설계에 관련된 모든 사람을 위한 것이다.
이 책의 구성
API 설계를 위한 일련의 원칙과 프로세스를 간략하게 설명하는 책이다. 이 책에서 다루는 ADDR 프로세스는 개인 및 여러 팀이 API 설계의 복잡성을 탐색하는 데 도움이 되도록 설계했다. 고객의 소리, 수행해야 할 작업, 프로세스 매핑과 같은 개념을 적용해 API 설계에 대한 객관적인 관점을 갖길 권장한다. 『웹 API 설계의 원칙』은 처음부터 새로운 예시를 통해 안내하지만 기존 API에도 사용될 수 있다.
이 책은 요구 사항 단계에서 고객에게 제공할 준비가 된 API 설계에 도달하는 것까지 API 설계의 모든 측면을 다룬다. 또한 개인, 팀 및 API 소비자 간의 좀 더 효과적인 의사소통을 위해 API 설계를 문서화하는 방법에 대한 지침도 포함돼 있다. 마지막으로 API 설계에 영향을 줄 수 있는 API 전달의 몇 가지 요소를 다룬다.
이 책은 5개의 부로 구성된다.
◆ 1부, ‘웹 API 설계 소개’에서는 API 설계가 중요한 이유에 대한 개요와 이 책에서 사용되는 API 설계 프로세스를 소개한다.
◆ 2부, ‘API 결과에 따른 조정’에서는 API를 설계하는 팀과 모든 고객 및 이해관계자 간의 조정을 보장한다.
◆ 3부, ‘API 후보 정의’에서는 API 프로파일에 원하는 결과를 제공하는 데 필요한 API 작업을 포함해 필요한 API를 식별한다.
◆ 4부, ‘API 설계’에서는 API 프로파일을 대상 개발자의 요구 사항을 충족하는 하나 이상의 API 스타일로 변환한다. 다루는 스타일에는 REST, gRPC, GraphQL, 이벤트 기반 비동기 API가 포함된다.
◆ 5부, ‘API 설계 개선’에서는 문서, 테스트 및 피드백에서 얻은 통찰력을 기반으로 API 설계를 개선한다. 또한 API를 마이크로서비스로 분해하는 장도 포함돼 있다.
마지막으로 이 책은 대규모 조직에서 설계 프로세스를 확장하는 방법에 대한 팁으로 마무리된다.
부록에서는 웹 기반 API에 사용되는 웹 언어인 HTTP에 대한 복습이 필요한 사람들을 위해 시작하는 데 도움이 되는 훌륭한 입문서를 제공한다.
목차
목차
- 1부. 웹 API 설계 소개
- 01장. API 설계 원칙
- 웹 API 설계 요소
- 비즈니스 관점에서의 기능
- 프로덕트 중심 사고
- 개발자 경험
- API 설계는 커뮤니케이션
- 소프트웨어 설계 원칙 다시 보기
- 모듈화
- 캡슐화
- 높은 응집도와 낮은 결합도
- 리소스 기반 API 설계
- 리소스는 데이터 모델이 아니다
- 리소스는 객체 또는 도메인 모델이 아니다
- 리소스 기반 API 메시지 교환
- 웹 API 설계 원칙
- 요약
- 웹 API 설계 요소
- 02장. API 설계 협업
- API 설계 프로세스를 사용하는 이유
- API 설계 프로세스 안티패턴
- 허술한 추상화 안티패턴
- 출시 버전마다 변경되는 설계 안티패턴
- 과잉 설계 안티패턴
- 미사용 API 안티패턴
- API 설계 우선 방법론
- API 설계 우선 방법론에서의 애자일
- 애자일 소프트웨어 개발 선언
- API 설계 우선 방법론의 민첩성
- ADDR 프로세스
- API 설계에서 DDD의 역할
- 모두가 참여하는 API 설계
- 프로세스를 효과적으로 적용
- 요약
- 2부. API 결과에 따른 조정
- 03장. 디지털 기능 식별
- 이해관계자의 의견 수렴
- 무엇이 디지털 기능인가?
- 수행해야 할 작업에 집중
- 작업 스토리가 무엇인가?
- 작업 스토리의 구성 요소
- API에 대한 작업 스토리 작성
- 방법 1: 문제가 판명된 경우
- 방법 2: 원하는 결과를 알 수 있는 경우
- 방법 3: 디지털 기능이 식별된 경우
- 작업 스토리의 어려움 극복
- 도전 1: 너무 상세한 작업 스토리
- 도전 2: 기능 중심의 작업 스토리
- 도전 3: 추가 사용자 콘텍스트가 필요한 작업 스토리
- 작업 스토리 캡처 기술
- 실제 API 설계 프로젝트
- 작업 스토리 예제
- 요약
- 04장. 액티비티와 단계 캡처
- 작업 스토리를 액티비티 및 단계로 확장
- 각 작업 스토리를 위한 액티비티 식별
- 각 액티비티를 단계로 분해
- 요구 사항이 명확하지 않을 때
- 공동 이해를 위한 EventStorming 사용
- EventStorming 동작 방식
- 단계 1. 비즈니스 도메인 이벤트 식별
- 단계 2. 이벤트 내러티브 만들기
- 단계 3. 내러티브 리뷰와 갭 식별
- 단계 4. 도메인 이해 확장
- 단계 5. 최종 내러티브 리뷰
- EventStorming의 장점
- 누가 참여해야 하는가?
- EventStorming 세션 진행
- 준비: 필요한 물품 수집
- 공유: EventStorming 세션 전달
- 실행: EventStorming 세션 수행
- 정리: 액티비티와 액티비티 단계 캡처
- 후속 조치: 세션 후 권장 사항
- 프로세스의 개인화
- 요약
- 작업 스토리를 액티비티 및 단계로 확장
- 3부. API 후보 정의
- 05장. API 경계 식별
- 피해야 할 API 경계 구분의 안티패턴
- 여러 기능을 제공하게 거대해진 하나의 API 안티패턴
- 사용 목적이 과도하게 집약된 API 안티패턴
- 도우미 API 안티패턴
- 제한된 콘텍스트와 하위 도메인 및 API
- EventStorming을 이용한 API 경계 찾기
- 액티비티를 통한 API 경계 찾기
- API 이름 지정과 범위
- 요약
- 피해야 할 API 경계 구분의 안티패턴
- 06장. API 모델링
- API 모델링
- API 프로파일의 구조
- API 모델링 프로세스
- 단계 1: API 프로파일 요약 캡처
- 단계 2: 리소스 확인
- 단계 3: 리소스 분류 정의
- 단계 4: 작업 이벤트 추가
- 단계 5: 작업 세부 정보 확장
- 시퀀스 다이어그램으로 API 모덜 검증
- API 중요도와 재사용 여부 평가
- 요약
- API 모델링
- 4부. API 설계
- 07장. REST API 설계
- REST API란?
- REST는 클라이언트와 서버다
- REST는 리소스 중심이다
- REST는 메시지 기반이다
- REST는 계층 구조를 지원한다
- REST는 코드온디멘드를 지원한다
- 하이퍼미디어 제어
- 언제 REST를 선택해야 하는가
- REST API 설계 프로세스
- 단계 1: 리소스 URL 경로 설계
- 단계 2: API 작업을 HTTP 메서드에 매핑
- 단계 3: 응답 코드 지정
- 단계 4: REST API 설계 문서화
- 단계 5: 공유하고 피드백 얻기
- 리소스 표현 형식 선택
- 리소스 직렬화
- 하이퍼미디어 직렬화
- 하이퍼미디어 메시징
- 시맨틱 하이퍼미디어 메시징
- REST 설계 패턴
- CRUD
- 리소스 라이프사이클 확장
- 싱글톤 리소스
- 백그라운드(대기) 작업
- REST에서 장기 실행 트랜잭션 처리
- 요약
- REST API란?
- 08장. RPC와 쿼리 기반 API 설계
- RPC 기반 API란?
- gRPC 프로토콜
- RPC 고려 사항
- RPC API 설계 프로세스
- 단계 1: RPC 동작 식별
- 단계 2: RPC 동작 세부 내역
- 단계 3: API 설계 문서화
- 쿼리 기반 API란?
- OData의 이해
- GraphQL 알아보기
- 쿼리 기반 API 설계 프로세스
- 단계 1: 리소스와 그래프 구조 설계
- 단계 2: 쿼리와 뮤테이션 동작 설계
- 단계 3: API 설계 문서화
- 요약
- RPC 기반 API란?
- 09장. 이벤트와 스트리밍을 위한 비동기 API
- API 폴링의 문제점
- 비동기 API가 갖는 새로운 가능성
- 메시징의 기초 다시 보기
- 메시지 스타일과 지역성
- 메시지의 구성 요소
- 메시지 브로커의 이해
- P2P 메시지 배포(큐)
- 팬아웃 메시지 배포(토픽)
- 메시지 스트리밍의 기초
- 비동기식 API
- 웹훅을 이용한 서버 알림
- SSE를 이용한 서버 푸시
- 웹소켓을 이용한 양방향 알림
- gRPC 스트리밍
- 비동기 API 스타일 선택
- 비동기 API 설계
- 명령 메시지
- 이벤트 알림
- Event-Carried 상태 전달 이벤트
- 이벤트 일괄 처리
- 이벤트 순서 정렬
- 비동기 API 문서 작성
- 요약
- 5부. API 설계 개선
- 10장. API에서 마이크로서비스까지
- 마이크로서비스란?
- 의견 조정 비용을 줄이는 마이크로서비스
- API와 마이크로서비스의 차이점
- 마이크로서비스의 복잡성 평가
- 셀프 서비스 인프라
- 독립적인 배포 일정
- 단일 팀 관리 체계로 전환
- 조직의 구조 및 조직 문화의 변화
- 데이터 소유권의 이동
- 분산 데이터 관리 및 거버넌스
- 분산 시스템의 어려움
- 복원력, 장애 조치, 분산 트랜잭션
- 코드 리팩토링 코드 공유의 어려움
- 동기식과 비동기식 마이크로서비스
- 마이크로서비스 아키텍처 스타일
- 직접적인 서비스 통신
- API 기반 오케스트레이션
- 셀 기반 아키텍처
- 마이크로서비스의 크기 최적화
- API를 마이크로서비스로 분해
- 단계 1: 후보 마이크로서비스 식별
- 단계 2: API 다이어그램에 마이크로서비스 추가
- 단계 3: 마이크로서비스 설계 캔버스를 이용해 캡처
- 마이크로서비스 설계의 추가 고려 사항
- 마이크로서비스 전환 시 고려 사항
- 요약
- 11장. 개발자 경험 향상시키기
- 모의 API 구현체 생성
- 정적 모의 API
- API 프로토타이핑
- README 기반 모의 API
- 개발 라이브러리와 SDK 제공
- 개발 라이브러리 제공 방법
- 개발 라이브러리의 버전 관리
- 개발 라이브러리 문서와 테스트
- API를 위한 CLI 제공
- 요약
- 모의 API 구현체 생성
- 12장. API 테스팅 전략
- 인수 테스트
- 자동화된 보안 테스트
- 운영 모니터링
- API 계약 테스트
- 효율적인 테스트를 위한 도구 선택
- API 테스트의 과제
- API 테스트는 선택이 아닌 필수
- 요약
- 13장. API 설계 문서화
- API 문서화의 중요성
- API 설명 형식
- OpenAPI 사양
- API Blueprint
- RAML
- JSON 스키마
- ALPS를 이용한 API 프로파일
- APIs.json을 이용한 API 검색 개선
- 코드 예제로 문서 확장
- 시작하기 코드 예제 먼저 작성
- 워크플로 예제로 문서 확장
- 에러 사례 및 운영 환경 준비가 된 예제
- 참조 문서에서 개발자 포털로
- 개발자 포털을 통한 API 채택 증가
- 훌륭한 개발자 포털의 요소
- 효과적인 API 문서화
- 질문1: API가 내 문제를 어떻게 해결하는가?
- 질문2: 각 API 작업은 어떤 문제를 지원하는가?
- 질문3: API 사용을 시작하려면 어떻게 해야 하는가?
- API 문서에서 테크니컬 라이터의 역할
- 실행 가능한 최소 포털
- 단계 1: 실행 가능한 최소 포털
- 단계 2: 개선
- 단계 3: 성장에 집중
- 개발자 포털을 위한 도구와 프레임워크
- 요약
- 14장. 변화를 위한 설계
- 기존 API 변경의 영향
- API 설계 격차 분석 수행
- API 소비자에게 가장 적합한 것이 무엇인지 결정
- 변경 전략
- 신뢰를 바탕으로 한 변경 관리
- API 버전 전략
- 일반적인 주요 변경 사항
- 호환되지 않는 변경 사항
- API 버전과 개정판
- API 버전 관리 방법
- API 버전 관리의 비즈니스 고려 사항
- API 지원 중단
- 사용 중단 정책 수립
- 지원 중단 발표
- API 안정성 계약 수립
- 요약
- 기존 API 변경의 영향
- 15장. API 보안
- API 보안의 위험성
- API 보안의 필수 방법
- API 보안의 구성 요소
- API 게이트웨이
- API 관리
- 서비스 메시
- 웹 애플리케이션 방화벽(WAF)
- 콘텐츠 전송 네트워크
- 지능형 API 보안
- API 게이트웨이 토폴로지
- API 관리 호스팅 방법
- API 네트워크 트래픽 고려 사항
- 토폴로지 1: API 게이트웨이를 API 서버로 직접 연결
- 토폴로지 2: 서비스에 대한 API 게이트웨이 라우팅
- 토폴로지 3: 여러 API 게이트웨이 인스턴스
- 아이디 및 액세스 관리
- 암호와 API 키
- API 토큰
- 참조를 전달하는 API 토큰과 값을 전달하는 API 토큰
- OAuth 2.0과 OpenID Connect
- API 게이트웨이를 직접 구축하기 전에 고려해야 할 사항
- 이유 1: API 보안은 움직이는 표적이다
- 이유 2: 예상보다 오래 걸린다
- 이유 3: 빠르게 작동하도록 만들기에는 많은 시간이 필요하다
- 개발 라이브러리에 대해
- 요약
- 16장. API 설계 여정의 지속
- API 스타일 가이드 설정
- 스타일 가이드 준수를 장려하는 방법
- 스타일 가이드 어조 선택
- API 스타일 가이드를 시작하기 위한 팁
- 여러 API 스타일 지원
- API 설계 검토 수행
- 문서 검토로 시작
- 표준 및 설계 일관성 확인
- 자동화된 테스트 범위 검토
- 미리 사용해보기 지원 추가
- 재사용 문화 개발
- 여정은 이제 막 시작됐다
- API 스타일 가이드 설정
- 부록. HTTP 입문서
- HTTP 개요
- URL
- HTTP 요청
- HTTP 응답
- 일반적인 HTTP 메서드
- HTTP 응답 코드
- 콘텐츠 협상
- 캐시 제어
- 조건부 요청
- HTTP에서 동시성 제어
- 요약
도서 오류 신고
정오표
정오표
[ p.91 : 표 3.2 ]
최근 냉수기 관련 소식 확인하기
->
최근 소식 확인하기
[ p.105: 8행 ]
팀 외부에 을 수 있지만
->
팀 외부에 있을 수 있지만
[ p.119 : 아래에서 6행 ]
각 PI의 기능적으로 구분하는 데 유용하며,
->
경계를 찾는 데 유용하며,
[ p.166 : 박스 ]
HATEAOS
->
HATEOAS
[ p.166 : 코드 ]
"_ link s"
->
"_links"
"sub mit"
->
"submit"
"au th ors"
->
"authors"
[ p.167 : 코드 ]
"sub mitted"
->
"submitted"
"_ link s"
->
"_links"
[ p.191 : 리스트 7.4]
"prof ile"
->
"profile"
[ p.229: 박스 하단 1행 ]
기초를 이해힐 필요가
->
기초를 이해할 필요가
"au th ors" -> "authors"