소득공제
PDF
eBook
OpenAPI와 스웨거를 활용한 실전 API 설계
요구사항 분석부터 비즈니스 모델 설계, 문서화, 자동화, 테스트, API 확장과 진화까지
스마트한 PDF 필기 기능을 사용해 보세요!
- PDF 안내
-
이 상품은 구매 후 지원 기기에서 예스24 eBook앱 설치 후 바로 이용 가능한 상품입니다.
이 분야의 이벤트
상세 이미지
소개
목차
|
[1부] OpenAPI 형식으로 기존 제품의 API 기술해 보기1장 API와 OpenAPI 소개 __1.1 API 생태계란?__1.2 API 기술하기____1.2.1 브리짓의 업무____1.2.2 브리짓 해법의 잠재력__1.3 OpenAPI란?____1.3.1 OpenAPI 정의서 예제__1.4 OpenAPI 정의서는 어디에 사용하는 것이 좋을까?__1.5 스웨거란?__1.6 REST란?__1.7 OpenAPI는 언제 사용하는가?____1.7.1 API 사용자____1.7.2 API 제공자____1.7.3 API 설계자__1.8 이 책의 구성__1.9 정리2장 API 요청 준비 __2.1 문제 정의____2.1.1 직판장 API 개요____2.1.2 직판장 API의 처음 두 가지 작업__2.2 포스트맨 준비__2.3 직판장 API__2.4 후기 목록 조회____2.4.1 GET 요청 구성____2.4.2 확인__2.5 후기 남기기____2.5.1 POST 요청 구성____2.5.2 확인__2.6 연습____2.6.1 고양이에 관한 진실 API____2.6.2 미니멀 아바타 API____2.6.3 덕덕고 검색 엔진 API____2.6.4 해적 은어 API__2.7 용사를 위한 HTTP__2.8 정리3장 OpenAPI 정의서 첫인상 __3.1 문제 정의__3.2 OpenAPI 명세 소개__3.3 YAML 훑어보기___3.3.1 JSON에서 YAML로__3.4 GET 연산 기술하기__3.5 GET 연산 확장__3.6 정리4장 스웨거 에디터로 OpenAPI 정의서 작성 __4.1 스웨거 에디터 소개___4.1.1 에디터 패널___4.1.2 UI 문서 패널___4.1.3 도구 메뉴___4.1.4 저장__4.2 스웨거 에디터에서 OpenAPI 정의서 작성___4.2.1 유효한 미니 OpenAPI 정의서___4.2.2 스웨거 에디터에서 OpenAPI 정의서 작성___4.2.3 검증__4.3 GET /reviews 추가__4.4 API 호출___4.4.1 GET /reviews 호출___4.4.2 OpenAPI 정의서에 서버 정보 추가___4.4.3 GET /reviews 다시 호출__4.5 정리5장 API 응답 기술하기 __5.1 HTTP 응답__5.2 문제 정의__5.3 놀라운 데이터 스키마의 세계__5.4 JSON 스키마___5.4.1 type 필드___5.4.2 객체에 필드 추가___5.4.3 minimum과 maximum___5.4.4 number와 integer__5.5 상태 코드__5.6 미디어 타입(MIME)__5.7 GET /reviews 응답 기술하기___5.7.1 초미니 응답___5.7.2 GET /reviews 200 응답 본문___5.7.3 응답 본문에 rating 필드 추가___5.7.4 message, uuid, userId 필드 추가__5.8 정리6장 자원 생성__6.1 문제 정의__6.2 POST /reviews와 요청 본문 기술하기___6.2.1 요청 본문___6.2.2 requestBody의 스키마__6.3 새 후기 생성___6.3.1 예시 추가로 try-it-out 기능 개선__6.4 경로 파라미터를 포함한 GET /reviews/{reviewId} 기술하기___6.4.1 경로 파라미터___6.4.2 reviewId 경로 파라미터 기술하기__6.5 후기 생성 확인__6.6 정리7장 인증과 인가 __7.1 문제 정의__7.2 인증 준비___7.2.1 도전 과제: POST /users 기술하기___7.2.2 도전 과제: POST /tokens 기술하기___7.2.3 해법: 정의서 내용 변경___7.2.4 사용자 및 토큰 생성 기능 확인__7.3 Authorization 헤더 추가___7.3.1 OpenAPI의 인가 처리 방식___7.3.2 OpenAPI 3.0.x에서 지원하는 인가(보안) 방식___7.3.3 보안 스킴에 Authorization 헤더 추가___7.3.4 POST /reviews에 보안 요구사항 추가___7.3.5 보안 기능 동작 확인__7.4 선택적으로 보안 적용__7.5 다른 방식의 보안 스킴__7.6 보안 스킴을 적용하는 일반적인 방법__7.7 정리8장 API 문서 준비와 호스팅 __8.1 문제 정의__8.2 API 정의서에 메타데이터 추가__8.3 마크다운으로 설명 작성___8.3.1 마크다운 기초___8.3.2 직판장 API 정의서에 마크다운 설명 추가__8.4 태그로 연산 그룹 짓기___8.4.1 GET /reviews 연산에 태그 추가___8.4.2 태그에 설명 추가___8.4.3 나머지 연산에 태그 추가__8.5 Netlify.com과 스웨거 UI로 API 문서 호스팅___8.5.1 OpenAPI 정의서로 스웨거 UI 준비___8.5.2 Netlify.com에서 호스팅__8.6 1부 마무리__8.7 정리[2부] OpenAPI와 스웨거를 활용한 API 설계 우선 방식 9장 웹 애플리케이션 설계 __9.1 펫시터 아이디어__9.2 펫시터 프로젝트 착수___9.2.1 추가 요구사항___9.2.2 팀 구조___9.2.3 API 중심 아키텍처___9.2.4 계획__9.3 도메인 모델링과 API___9.3.1 API에 사용할 도메인 모델링___9.3.2 직판장 API 돌아보기__9.4 펫시터 도메인 모델___9.4.1 모델에 사용되는 개념___9.4.2 사용자 모델___9.4.3 구인 공고와 반려견 모델__9.5 펫시터 사용자 스토리___9.5.1 사용자 스토리란 무엇인가?___9.5.2 사용자 스토리 수집___9.5.3 사용자 스토리 매핑__9.6 정리10장 OpenAPI를 사용한 API 설계 __10.1 문제___10.1.1 도메인 모델을 OpenAPI로 전환___10.1.2 재사용성 보장__10.2 스키마 생성___10.2.1 스키마를 포함하는 OpenAPI 파일___10.2.2 공통 스키마 참조___10.2.3 User 스키마___10.2.4 Job 스키마___10.2.5 Dog 스키마___10.2.6 JobApplication 스키마__10.3 API 연산과 CRUD___10.3.1 API 요청과 응답 정의___10.3.2 사용자 스토리와 CRUD 설계__10.4 펫시터 API___10.4.1 User 스키마에 필요한 연산___10.4.2 Job 스키마에 필요한 연산___10.4.3 JobApplication 스키마에 필요한 연산__10.5 정리11장 API 설계 우선 방식에 변경 워크플로 구축 __11.1 문제__11.2 변경 논의와 대응__11.3 워크플로 엔진으로서의 깃허브___11.3.1 단일 진실 출처___11.3.2 변경 제안___11.3.3 변경 수용___11.3.4 변경 비교 확인__11.4 깃허브 워크플로 통합___11.4.1 깃허브와 진실의 출처 구성___11.4.2 깃허브 워크플로 단계__11.5 워크플로 실무___11.5.1 DELETE /jobs/{id} 추가 제안___11.5.2 변경 검토 및 수용___11.5.3 오래된 브랜치와 최신 브랜치 비교___11.5.4 11장에서 수행한 내용__11.6 정리12장 프론트엔드 코드 구현과 변경 대응 __12.1 문제__12.2 프리즘 목 서버 구성___12.2.1 프리즘 설치___12.2.2 프리즘 동작 확인__12.3 목 서버를 바탕으로 프론트엔드 개발___12.3.1 OpenAPI 정의서에 예제 추가___12.3.2 프리즘에 examples 적용__12.4 누락된 API 연산 식별___12.4.1 새 연산 추가 검토___12.4.2 새 연산 설계___12.4.3 프리즘으로부터 반환받을 목 데이터 선정___12.4.4 변경 제안___12.4.5 curl 예제__12.5 정리13장 Node.js와 스웨거 코드젠으로 백엔드 구축 __13.1 문제__13.2 스웨거 코드젠 소개___13.2.1 클라이언트 코드 생성___13.2.2 서버 코드 생성___13.2.3 스웨거 제너레이터__13.3 백엔드 구조___13.3.1 백엔드 코드 생성___13.3.2 백엔드 구조 분석___13.3.3 OpenAPI 수정 내용__13.4 백엔드 OpenAPI 수정___13.4.1 operation ID 추가___13.4.2 API 연산에 태그 지정___13.4.3 백엔드 스텁 재생성__13.5 백엔드 코드 실행과 테스트___13.5.1 포스트맨으로 테스트___13.5.2 입력값 검증 테스트___13.5.3 프리즘으로 결괏값 검증__13.6 몽구스로 데이터베이스 저장___13.6.1 API 수정___13.6.2 몽고디비 사용 준비___13.6.3 몽구스 설정___13.6.4 모델 생성__13.7 API 메소드 구현__13.8 정리14장 웹 애플리케이션 통합 및 출시 __14.1 문제___14.1.1 인증___14.1.2 코드 조직___14.1.3 백엔드와 프론트엔드 컴포넌트를 함께 제공__14.2 인가 구현___14.2.1 보안 스킴 생성___14.2.2 ‘Login’ 행위 추가___14.2.3 연산 보안 정의__14.3 리포지터리 관리___14.3.1 기존 구조 유지___14.3.2 공유 깃 리포지터리 사용___14.3.3 코드와 API 정의서를 하나의 리포지터리에 통합___14.3.4 결정 및 리팩터링__14.4 통합 웹 서버 구성___14.4.1 URL 설계___14.4.2 서버 구성__14.5 정리[3부] 제품 출시 이후 API 확장과 진화 15장 2차 API 설계 __15.1 첫 번째 개발 스프린트 검토__15.2 다음 스프린트 계획__15.3 새 기능 준비___15.3.1 도메인 모델 재검토___15.3.2 사용자 스토리 검토__15.4 개발자 경험 개선___15.4.1 일관성___15.4.2 에러 처리___15.4.3 입력값 유효성 검증___15.4.4 버전 관리와 진화__15.5 정리16장 OpenAPI 합성을 사용한 스키마 설계 __16.1 문제__16.2 도메인 모델 다형성과 상속__16.3 스키마 업데이트___16.3.1 Pet 스키마___16.3.2 Dog 스키마___16.3.3 Cat 스키마__16.4 OpenAPI의 다형성과 상속___16.4.1 Dog 스키마와 Cat 스키마 안에서 합성___16.4.2 Pet 스키마 안에서 합성__16.5 OpenAPI 구분자 추가__16.6 정리17장 컬렉션 엔드포인트에 필터와 페이징 적용 __17.1 문제__17.2 필터링 설계___17.2.1 프로젝션 필터___17.2.2 셀렉션 필터___17.2.3 중첩 스키마 처리___17.2.4 쿼리 언어___17.2.5 특수 관례__17.3 펫시터 필터링___17.3.1 필터링 기준 필드 선정___17.3.2 OpenAPI에 필터링 적용___17.3.3 필터 포함 요청__17.4 페이징 설계___17.4.1 오프셋 기반, 페이지 기반 페이징___17.4.2 커서 기반 페이징__17.5 펫시터에 페이징 적용___17.5.1 OpenAPI에 페이징 적용___17.5.2 요청 예제 확장__17.6 정렬 설계___17.6.1 단일 필드 정렬___17.6.2 다중 필드 정렬___17.6.3 파라미터 타입 일관성__17.7 펫시터에 정렬 적용___17.7.1 정렬 필드___17.7.2 정렬 파라미터 설계___17.7.3 OpenAPI 정의서에 정렬 기능 추가___17.7.4 필터링, 페이징, 정렬이 모두 적용된 요청 예제__17.8 정리18장 problem+json을 활용한 예외 처리 __18.1 문제 정의__18.2 에러 분류___18.2.1 실패 상황 찾기___18.2.2 공통 에러 패턴__18.3 에러 응답 요구사항__18.4 OAS 도구 형식__18.5 problem+json 형식__18.6 OpenAPI 정의서에 에러 응답 추가___18.6.1 에러 스키마 생성___18.6.2 연산에 에러 응답 추가__18.7 에러 처리 가이드___18.7.1 프론트엔드 개발___18.7.2 백엔드 개발__18.8 정리19장 고급 JSON 스키마를 활용한 입력값 유효성 검증 __19.1 문제 정의__19.2 유효성 검증 세부 기능___19.2.1 readOnly, writeOnly 프로퍼티___19.2.2 숫자 제약사항 강제___19.2.3 문자열 형식 강제___19.2.4 배열 제약사항 강제___19.2.5 열거형 정의___19.2.6 필수 프로퍼티와 선택 프로퍼티 목록___19.2.7 기본값 지정__19.3 펫시터 스키마 업데이트___19.3.1 User 스키마___19.3.2 Job 스키마___19.3.3 JobApplication 스키마___19.3.4 Pet, Dog, Cat 스키마__19.4 정리20장 API 버전 관리와 중대 변경 처리 __20.1 문제 정의__20.2 중대 변경이란?__20.3 중대 변경 출시___20.3.1 중대 변경 조율___20.3.2 API 버전 관리___20.3.3 미디어 타입을 활용한 스키마 버전 구분___20.3.4 기능 추가/삭제 예고__20.4 정리21장 API 출시 전 체크리스트 __21.1 공개 API의 장점과 단점__21.2 체크리스트__21.3 API 정상 동작___21.3.1 API 단위 테스트___21.3.2 종단 간 테스트__21.4 문서화__21.5 API 일관성 확보__21.6 유효성 검증과 에러 보고__21.7 API 로드맵과 인덱스 공개__21.8 변경 전략__21.9 보안 개선__21.10 API 모니터링___21.10.1 지표 수집 구성__21.11 API 출시___21.12 정리부록 A 스웨거 2.0, OpenAPI 3.0, OpenAPI 3.1부록 B [한국어판 특별부록] 스프링 부트 웹서비스에 스웨거를 입혀 활용하는 방법
|
저자 소개 3
Josh Ponelat
스마트베어(SmartBear)의 스웨거 오픈소스를 담당하고 있다. API 관련 마찰을 최소화하고 팀이 더 나은 도구를 만들도록 돕는 것을 목표로 한다. 조시는 지구의 남쪽 끝에 있는 남아프리카 공화국에 거주하는 커피 애호가이며 말장난을 즐긴다. 어디에서든 ‘ponelat’이라는 계정을 사용하며, 아마추어 지도 제작, 소형 제품 제작, 고급 노트 필기법에 관심이 있다면 주저하지 말고 슬랙이나 그 밖의 온라인 포럼에서 조시를 찾아보자.
Lukas Rosenstock
스타트업과 대규모 조직을 대상으로 API 라이프사이클 관련 컨설팅, 개발, 기술 문서 작성을 지원하는 프리랜서 기업가다. 유럽의 중심부인 독일에 살고 있으며, 맥주를 좋아하지 않는 이상한 독일인이자 커피를 마시지 않는 이상한 엔지니어다. 맥주와 커피 대신에 차를 즐겨 마신다. API 관련 일이나 코딩으로 바쁘지 않을 때는 밤 늦게까지 보드 게임을 즐기고 효과적인 이타주의로 더 나은 세상을 만드는 방법을 고민한다. 트위터(@LukasRosenstock)에서 루카스를 만날 수 있다.
생태계에 조금이라도 보탬이 되려는 개발자. 개인 깃허브 페이지(https://github.com/Homo Efficio/dev-tips)에 잡다한 문제 해결 기록을 공유하고 있으며, 계단 오르기로 체력과 호흡을 개선하며 활력을 되찾고 있다. 네이버제트에서 제페토 서비스를 만들고 있다.
『OpenAPI와 스웨거를 활용한 실전 API 설계』(책만, 2023), 『실전 스프링 부트』(제이펍, 2023), 『스프링 부트 실전 활용 마스터』(책만, 2021), 『엔터프라이즈 데이터 플랫폼 구축』(책만, 2020) 등을 번역했으며, 적은 양이라도 꾸준히 번역 작업을 이어갈 생각이다.
오명운의 다른 상품
품목정보
- 발행일
- 2024년 01월 31일
- 지원기기
- 크레마, PC(윈도우 - 4K 모니터 미지원), 아이폰, 아이패드, 안드로이드폰, 안드로이드패드, 전자책단말기(저사양 기기 사용 불가), PC(Mac)
- 파일/용량
- PDF(DRM) | 16.49MB ?
- 글자 수/ 페이지 수
- 약 524쪽 ?
- ISBN13
- 9791189909598
출판사 리뷰
|
이 책에서 다루는 내용이 책은 API를 기술하고(describe) 설계하는(design) 방법을 다룬다. OpenAPI 세상으로 인도하는 입문서로서, 설계 우선 원칙을 실천하는 API 개발자가 사용하는 도구와 사례를 들여다본다. OpenAPI 정의서를 읽고 쓰는 기초부터 시작해서 도메인 설계, 워크플로 변경, API 디자인 패턴으로 나아간다. OpenAPI와 API 설계에 초점을 맞추지만 API 라이프사이클 전반에 걸친 주제를 모두 다루려고 노력했으며 기술 관점과 프로젝트 관리 관점을 두루 살펴볼 수 있다. OpenAPI가 어떤 문제를 해결해 주는지, 왜 존재하는지, 어떻게 사용하는지 이해하고 자신감을 갖는 데 이 책이 도움이 되었으면 한다.- OpenAPI 형식으로 기존 제품의 API를 기술해 본다- OpenAPI와 스웨거를 활용해 API 설계 우선 방식(design first approach)을 적용해 본다- 제품 출시 이후 API 확장과 진화 방법을 알아본다- OpenAPI 구문과 구조를 학습한다- 스웨거를 사용해 OpenAPI 정의서를 생성한다- 프로세스를 자동화하고 코드를 자동 생성해 본다- 기능 조직 간 협업 방식을 배운다이 책의 대상 독자API에 흥미를 갖고 설계 우선 방식으로 API를 활용해 보려는 소프트웨어 개발자가 읽어야 하는 책이다. 프론트엔드 또는 백엔드 개발자, 제품 관리자, QA 테스터, 심지어 CEO까지 API 관련 의사결정을 내려야 하는 모두가 읽어야 한다. 특정 주제를 심도 깊이 이해하고 있지 않더라도 책을 읽을 수 있도록 주의를 기울였으며, JSON이나 HTTP 같은 개념에 익숙하다면 책을 읽는 데 아무런 문제가 없을 것이다. 또한 간단한 복습과 외부 자료에 대한 링크도 많이 담았다.이 책의 구성[1부] OpenAPI 형식으로 기존 제품의 API를 기술해 보기· 1장: API를 기술하는 의의와 방법· 2장: API를 탐험하는 데 사용하는 도구인 포스트맨(Postman) 설명· 3장: 이미 만들어져 있는 직판장(Farmstall) API를 기술하는 방법· 4장: 스웨거 에디터 사용 방법· 5장: 기본적인 API 요청과 응답 기술해 보기· 6장: 요청 본문과 응답 본문 다뤄 보기· 7장: 인증과 인가 알아보기· 8장: 스웨거 UI를 사용해 API 문서를 제공하는 웹사이트를 호스팅하는 방법[2부] 백지 상태에서 OpenAPI와 스웨거를 활용해 API를 설계해 보기· 9장: 2부 전반에 걸쳐 다루게 될 펫시터(PetSitter) 프로젝트 소개· 10장: API를 설계하고 OpenAPI를 사용해 API를 기술하는 과정· 11장: API 설계 변경을 처리할 수 있는 깃(Git) 기반의 워크플로 소개· 12장: API 사용자 입장에서 API에 대한 목(mock)을 활용하고 변경에 대응하는 방법· 13장: 스웨거 코드젠을 사용해 API를 구현하는 방법· 14장: API를 사용할 수 있도록 준비를 마치고 프론트엔드와 백엔드를 통합하는 과정[3부] 2부에서 작성한 API 설계를 확장하고 진화시켜 보기· 15장: 다음 단계의 API 반복(iteration)에 대한 계획 세우기· 16장: JSON 스키마 합성(composition)을 사용한 도메인 모델 확장· 17장: API에 필터링, 페이징, 정렬 기능 추가· 18장: problem+json 응답 형식을 알아보고 API에 에러 처리 적용하기· 19장: JSON 스키마를 확장하고 입력값 유효성 검증 적용하기· 20장: API 버전 관리와 중대 변경(breaking change)을 처리하는 방법· 21장: API 최종 출시 전 체크리스트[부록] 스웨거 2.0, OpenAPI 3.0, OpenAPI 3.1의 차이점[한국어판 특별부록] 스프링 부트 웹서비스에 스웨거를 입혀 활용하는 방법 지은이의 말REST API 문서 정의와 작성을 도와주는 도구 모음인 스웨거를 사용하면 보안이 적용된 굉장히 쓸모 있는 API 설명 문서를 제공할 수 있다. 스웨거는 특정 회사에 종속적이지 않은 표준인 OpenAPI 명세를 구현하므로, 스웨거를 사용하면 구글이나 마이크로소프트, 아마존에서 수용한 것과 동일한 표준을 사용하게 된다. 이 책에서는 설계 우선 접근방식(design-first approach)을 소개한다. API 설계를 처음 접하는 개발자는 개념 정립부터 제품 수준에 이르기까지 API의 전체 생애주기를 익힐 수 있다. 점진적으로 예제를 완성해가면서 API 설계와 개발에서 해야 할 일과 하지 말아야 할 일을 배워본다. 문서와 개발자 친화적인 목(mock)이나 클라이언트 SDK를 자동으로 생성해주는 도구를 사용해서 비즈니스 요구사항에 맞는 API를 설계하는 실무 경험을 쌓을 수 있다. 스웨거나 OpenAPI에 대한 아무런 사전 지식이 없더라도 웹 개발자라면 충분히 읽을 수 있다.옮긴이의 말인터넷이 세상에 나온 지 그리 오래되지 않았을 때, 집 밖에 나가지 않고 인터넷만으로 얼마나 잘 지낼 수 있는지를 실험해보는 체험 예능 컨텐츠가 있었던 걸로 기억합니다. 하지만 이제 그런 예능은 아무도 보지 않을 것 같습니다. 스마트폰을 사용할 수 있다면 누구든 인터넷만으로 불편 없는 삶을 영위할 수 있다는 사실을 누구나 알고 있으니까요. 이처럼 손 안에서 몇 번의 스와이프와 클릭만으로 물건을 받아 사용할 수 있고 음식을 배달받아 먹으며, SNS를 통해 이 모든 것을 자랑까지 할 수 있게 된 편리한 세상을 돋보기로 계속 확대하면서 들여다보면 그 마디마디에 API가 숨어 있음을 확인할 수 있을 것입니다. API는 다양한 소프트웨어의 연결점 역할을 하면서 이 세상을 든든하게 떠받치고 있습니다.소프트웨어의 연결점 역할을 하는 API는 소프트웨어 개발자들에게는 의사소통 수단으로 사용됩니다. 원활한 의사소통을 위해서는 주고받는 데이터 형식과 호출 방식을 정의하는 규격과 그에 대한 친절한 설명을 작성해야 합니다. 즉 API를 기술해야(describe) 합니다. OpenAPI는 HTTP 프로토콜 기반의 HTTP API를 기술하는 표준 명세이며, 표준이 있으면 자동화가 가능해지므로 OpenAPI를 통해 많은 작업을 자동화할 수 있습니다. 이 책은 OpenAPI를 사용해서 API 정의서를 기술하는 방법을 설명합니다. 그걸로 그쳤다면 그다지 재미없는 책이 될 수도 있었을 텐데, 작은 웹 서비스의 요구 사항을 정리하고, 사용자 스토리를 작성하고, 이를 바탕으로 비즈니스 도메인 모델을 설계하고, 이를 반영한 API를 설계하고, OpenAPI를 사용해서 API 정의서를 작성하고, 정의서를 바탕으로 자동화를 이용해 개발 생산성을 높이고, 시간이 지남에 따라 API를 매끄럽게 진화시켜 확장하는 방법까지 그야말로 모든 것을 다루고 있습니다.API를 설계하고는 있지만 어쩌면 별다른 학습이나 기준 없이 편의성만을 생각하며 설계하고 구현하다가 나중에 확장하기 어렵게 되는 안타까운 일이 실무적으로 많이 발생하는데, 이 책에 나오는 모범 사례를 읽다 보면 자연스럽게 확장성 있는 API를 설계하는 데 필요한 지식을 얻을 수 있습니다.이런 내용만으로도 유익할 텐데, 이 모든 과정을 지루하고 딱딱한 설명이 아니라 실제로 작은 프로젝트 팀이 구성되고 각자의 역할을 수행하며 난관에 부딪치고 해결하는 모습을 묘사하는 형식으로 전개하고 있어 흥미진진하고 재미있기까지 합니다. 게다가 예제를 위해 간혹 특정 기술을 사용하고 있기는 하지만 본질적으로 특정 도구에 종속되는 내용이 아니라서, 한마디로 API를 만들고 활용하는 개발자 모두에게 재미있고 유익한 책입니다.이 책의 내용이 전반적으로 OpenAPI를 사용해 새로운 시스템을 설계하고 만들어 가는 과정을 보여주고 있어서 이미 만들어진 시스템에는 적용할 수 없는 건가라는 의문이 들 수도 있는데, 다행스럽게도 기존 시스템에도 적용할 방법이 있습니다. 국내에서 API 서버 개발에 가장 널리 사용되는 스프링 부트 기반의 API 서버라면 아주 간단한 설정과 애너테이션만으로도 스웨거 UI 사이트를 자동으로 만들 수 있습니다. 단순한 예제지만 실무적으로 꽤 큰 도움이 될 것이라 생각해서 한국어판 특별부록으로 추가했습니다.코딩도 그렇지만 번역도 늘 볼 때마다 개선점이 눈에 보입니다. 아마 원서를 작성한 저자들도 마찬가지일 겁니다. 번역자는 일차적으로는 원서를 우리글로 옮기는 일을 하는 사람이지만, 훌륭한 번역자는 먼저 독자의 입장에서 원서를 읽고 불편했던 점을 찾아 개선하고 최종 독자에게는 더 나은 결과물을 보여주는 사람이라고 생각합니다. 이번에도 모자람이 있겠지만 훌륭한 번역자 흉내라도 내보고 싶어서 원서보다 나은 역서를 목표로 번역 작업을 했습니다. 모쪼록 독자분들이 읽어나가시면서 마치 애초부터 한글로 쓰여진 책인 것처럼 술술 읽으실 수 있기를 욕심내어 바라봅니다.
|
