API 설계로 고민하는 모든 분께 복잡한 웹 API 세계의 길잡이가 되어 줄 단 하나의 책! 『웹 개발자를 위한 API 디자인 패턴』, 드디어 출간! 개발자라면 누구나 경험해봤을 것이다. 새로운 웹 API를 마주할 때마다 반복되는 감정의 롤러코스터를. 흥분, 당혹감, 짜증, 순응, 그리고 끝으로 꺼림칙한 평온함까지. 이 모든 것은 단순한 CRUD 메서드로는 해결되지 않는 세계다. 『웹 개발자를 위한 API 디자인 패턴』은 이 복잡하고 중요한 세계를 체계적으로, 실용적으로 풀어낸 필독서다. 구글 출신의 API 디자인 전문가 JJ 지웍스가 실무 경험을 바탕으로 다양한 웹 API 설계의 핵심 패턴을 정리한 이 책은, 난해한 개념을 현실적인 예제와 연계하여 설명했으며, 이론적 접근과 실무적 해결책을 조화롭게 결합하여 개발자들로부터 높은 평가를 받았다. 이 책을 통해 개발자는 리소스 식별부터 보안 구현까지 검증된 패턴을 익히고, 팀 내 일관된 API 설계 원칙을 세우며, 구글 수준의 전문 노하우와 체계적 의사결정 프레임워크를 바탕으로 TypeScript 기반의 실제 구현 가능한 코드까지 모두 얻을 수 있을 것이다.

추천의 글 지은이 소개 지은이의 말 감사의 말 옮긴이 소개 옮긴이의 말 들어가며 1부. 서론 1장 API 소개 1.1 웹 API 1.2 API의 중요성 1.3 리소스 지향 API 1.4 ‘좋은’ API 1.4.1 운영성 1.4.2 표현성 1.4.3 단순함 1.4.4 예측 가능성 요약 2장 API 디자인 패턴 소개 2.1 API 디자인 패턴 2.2 왜 API 디자인 패턴이 중요한가? 2.3 API 디자인 패턴 분석 2.3.1 이름과 시놉시스 2.3.2 동기 2.3.3 개요 2.3.4 구현 2.3.5 트레이드오프 2.4 사례 연구: Twapi, 트위터 모사 API 2.4.1 개요 2.4.2 메시지 목록 2.4.3 데이터 내보내기 요약 2부 디자인 원칙 3장 이름 붙이기 3.1 왜 이름이 중요한가? 3.2 ‘좋은’ 이름이란 무엇인가? 3.2.1 표현성 3.2.2 단순성 3.2.3 예측 가능성 3.3 언어, 문법, 구문 3.3.1 언어 3.3.2 문법 3.3.3 구문 3.4 맥락 3.5 데이터 타입과 단위 3.6 사례 연구: 나쁜 이름을 붙이면 어떤 일이 일어나는가? 3.7 연습문제 요약 4장 리소스 범위와 계층 4.1 리소스 레이아웃이란? 4.1.1 관계 타입 4.1.2 개체 관계 다이어그램 4.2 올바른 관계 선택 4.2.1 관계를 세워야 하는가? 4.2.2 참조와 인라인 데이터 4.2.3 계층 관계 4.3 안티패턴 4.3.1 모든 것의 리소스화 4.3.2 깊은 계층 관계 4.3.3 모든 것의 인라인화 4.4 연습문제 요약 5장 데이터 타입과 기본값 5.1 데이터 타입 개괄 5.1.1 누락 vs null 5.2 불리언 5.3 숫자 5.3.1 상하한 5.3.2 기본값 5.3.3 직렬화 5.4 문자열 5.4.1 상하한 5.4.2 기본값 5.4.3 직렬화 5.5 열거형 5.6 리스트 5.6.1 원자성 5.6.2 상하한 5.6.3 기본값 5.7 맵 5.7.1 상하한 5.7.2 기본값 5.8 연습문제 요약 3부 기초 패턴 6장 리소스 식별 6.1 식별자의 뜻 6.2 좋은 식별자란? 6.2.1 용이성 6.2.2 고유성 6.2.3 영속성 6.2.4 신속성과 생성의 용이함 6.2.5 예측 불가능성 6.2.6 가독성, 공유성, 검증성 6.2.7 정보 밀도 6.3 좋은 식별자의 형태 6.3.1 데이터 타입 6.3.2 문자 세트 6.3.3 식별자 포맷 6.3.4 체크섬 6.3.5 리소스 타입 6.3.6 계층과 고유 범위 6.4 식별자 구현 6.4.1 크기 6.4.2 식별자 생성 6.4.3 묘석화 6.4.4 체크섬 6.4.5 데이터베이스 스토리지 6.5 UUID 6.6 연습문제 요약 7장 표준 메서드 7.1 서론 7.2 개괄 7.3 구현 7.3.1 어떤 메서드를 지원해야 하는가? 7.3.2 멱등성과 부수 효과 7.3.3 get 7.3.4 list 7.3.5 create 7.3.6 update 7.3.7 delete 7.3.8 replace 7.3.9 최종 API 정의 7.4 트레이드오프 7.5 연습문제 요약 8장 부분 업데이트와 부분 취득 8.1 서론 8.1.1 부분 취득 8.1.2 부분 업데이트 8.2 개괄 8.3 구현 8.3.1 전달 8.3.2 맵과 중첩 인터페이스 8.3.3 반복적 필드 8.3.4 기본값 8.3.5 묵시적 필드 마스크 8.3.6 동적 데이터 구조 업데이트 8.3.7 유효하지 않은 필드 8.3.8 최종 API 정의 8.4 트레이드오프 8.4.1 보편 지원 8.4.2 기타 구현 8.5 연습문제 요약 9장 사용자 메서드 9.1 서론 9.1.1 표준 메서드를 쓰면 안 될까? 9.2 개요 9.3 구현 9.3.1 부수 효과 9.3.2 리소스 vs 컬렉션 9.3.3 무상태 사용자 메서드 9.3.4 최종 API 정의 9.4 트레이드오프 9.5 연습문제 요약 10장 장기 실행 작업 10.1 서론 10.2 개요 10.3 구현 10.3.1 LRO의 형태 10.3.2 리소스 계층 10.3.3 이행 10.3.4 에러 처리 10.3.5 진행 사항 모니터링 10.3.6 작업 취소 10.3.7 작업 일시 정지 및 재개 10.3.8 작업 탐색 10.3.9 영속성 10.3.10 최종 API 정의 10.4 트레이드오프 10.5 연습문제 요약 11장 재수행 가능 작업 11.1 서론 11.2 개괄 11.3 구현 11.3.1 잡 리소스 11.3.2 run 사용자 메서드 11.3.3 잡 실행 리소스 11.3.4 최종 API 정의 11.4 트레이드오프 11.5 연습문제 요약 4부 리소스 관계 12장 싱글톤 서브리소스 12.1 서론 12.1.1 왜 싱글톤 서브리소스를 사용해야 하는가? 12.2 개괄 12.3 구현 12.3.1 표준 메서드 12.3.2 재설정 12.3.3 계층 구조 12.3.4 최종 API 정의 12.4 트레이드오프 12.4.1 원자성 12.4.2 단일 서브리소스 조건 12.5 연습문제 요약 13장 교차 참조 13.1 서론 13.2 개괄 13.3 구현 13.3.1 참조 필드 이름 13.3.2 데이터 무결성 13.3.3 값 대 참조 13.3.4 최종 API 정의 13.4 트레이드오프 13.5 연습문제 요약 14장 연관 리소스 14.1 서론 14.2 개괄 14.2.1 연관성 별칭 메서드 14.3 구현 14.3.1 연관 리소스 이름붙이기 14.3.2 표준 메서드 동작 14.3.3 고유성 14.3.4 읽기 전용 필드 14.3.5 연관 별칭 메서드 14.3.6 참조 무결성 14.3.7 최종 API 정의 14.4 트레이드오프 14.4.1 복잡성 14.4.2 연관성 분리 14.5 연습문제 요약 15장 add 및 remove 사용자 메서드 15.1 서론 15.2 개괄 15.3 구현 15.3.1 연관 리소스 나열 15.3.2 데이터 무결성 15.3.3 최종 API 정의 15.4 트레이드오프 15.4.1 비상호관계 15.4.2 관계 메타데이터 15.5 연습문제 요약 16장 다형성 16.1 서론 16.2 개괄 16.3 구현 16.3.1 다형성 리소스 사용 여부 결정 16.3.2 다형성 구조 16.3.3 다형성 동작 16.3.4 왜 다형성 메서드를 사용하지 않는가? 16.3.5 최종 API 정의 16.4 트레이드오프 16.5 연습문제 요약 5부 선택적 작업 17장 복사와 이동 17.1 서론 17.2 개괄 17.3 구현 17.3.1 식별자 17.3.2 자식 리소스 17.3.3 관련 리소스 17.3.4 외부 데이터 17.3.5 상속 메타데이터 17.3.6 원자성 17.3.7 최종 API 정의 17.4 트레이드오프 17.5 연습문제 요약 18장 배치 작업 18.1 서론 18.2 개괄 18.3 구현 18.3.1 원자성 18.3.2 컬렉션 작업 18.3.3 결과 정렬 18.3.4 공통 필드 18.3.5 부모 간 작업 18.3.6 배치 get 18.3.7 배치 delete 18.3.8 배치 create 18.3.9 배치 update 18.3.10 최종 API 정의 18.4 트레이드오프 18.5 연습문제 요약 19장 기준 기반 삭제 19.1 서론 19.2 개괄 19.3 구현 19.3.1 결과 필터링 19.3.2 기본 검증 제한 19.3.3 결과 개수 19.3.4 결과 샘플 세트 19.3.5 일관성 19.3.6 최종 API 정의 19.4 트레이드오프 19.5 연습문제 요약 20장 익명 기록 20.1 서론 20.2 개괄 20.3 구현 20.3.1 일관성 20.3.2 최종 API 정의 20.4 트레이드오프 20.5 연습문제 요약 21장 페이징 21.1 서론 21.2 개괄 21.3 구현 21.3.1 페이지 크기 21.3.2 페이지 토큰 21.3.3 총 개수 21.3.4 리소스 내부 페이징 21.3.5 최종 API 정의 21.4 트레이드오프 21.4.1 양방향 페이징 21.4.2 임의 윈도우 21.5 안티패턴: 오프셋과 한도 21.6 연습문제 요약 22장 필터링 22.1 서론 22.2 개괄 22.3 구현 22.3.1 구조 22.3.2 필터 문법 및 동작 22.3.3 최종 API 정의 22.4 트레이드오프 22.5 연습문제 요약 23장 가져오기와 내보내기 23.1 서론 23.2 개괄 23.3 구현 23.3.1 import 및 export 메서드 23.3.2 스토리지 시스템 상호작용 23.3.3 리소스-바이트 변환 23.3.4 일관성 23.3.5 식별자와 충돌 23.3.6 관련 리소스 23.3.7 실패와 재시도 23.3.8 필터링 및 필터 마스크 23.3.9 최종 API 정의 23.4 트레이드오프 23.5 연습문제 요약 6부 안전과 보안 24장 버전 작성과 호환성 24.1 서론 24.2 개괄 24.2.1 호환성이란 24.2.2 하위 호환성 정의 24.3 구현 24.3.1 영구적 안정성 24.3.2 애자일 불안정성 24.3.3 시맨틱 버전 작성 24.4 트레이드오프 24.4.1 세세함 vs 단순함 24.4.2 안정성 vs 새 기능 24.4.3 만족도 vs 범용성 24.5 연습문제 요약 25장 논리 삭제 25.1 서론 25.2 개괄 25.3 구현 25.3.1 삭제 지시 25.3.2 표준 메서드 수정 25.3.3 삭제 취소 25.3.4 말소 25.3.5 만료 25.3.6 참조 무결성 25.3.7 다른 메서드에의 영향성 25.3.8 버전 간 논리 삭제 25.3.9 최종 API 정의 25.4 트레이드오프 25.5 연습문제 요약 26장 요청 중복 방지 26.1 서론 26.2 개괄 26.3 구현 26.3.1 요청 식별자 26.3.2 응답 캐싱 26.3.3 일관성 26.3.4 요청 ID 충돌 26.3.5 캐시 만료 26.3.6 최종 API 정의 26.4 트레이드오프 26.5 연습문제 요약 27장 요청 검증 27.1 서론 27.2 개괄 27.3 구현 27.3.1 외부 의존성 27.3.2 특수 부수 효과 27.3.3 최종 API 정의 27.4 트레이드오프 27.5 연습문제 요약 28장 리소스 리비전 28.1 서론 28.2 개괄 28.3 구현 28.3.1 리비전 식별자 28.3.2 리비전 생성 28.3.3 특정 리비전 취득 28.3.4 리비전 목록 나열 28.3.5 과거 리비전 되돌리기 28.3.6 리비전 삭제 28.3.7 자식 리소스 다루기 28.3.8 최종 API 정의 28.4 트레이드오프 28.5 연습문제 요약 29장 요청 재시도 29.1 서론 29.2 개괄 29.2.1 클라이언트 측 재시도 타이밍 29.2.2 서버 특정 재시도 타이밍 29.3 구현 29.3.1 재시도 가능성 29.3.2 지수 백오프 29.3.3 Retry-After 29.3.4 최종 API 정의 29.4 트레이드오프 29.5 연습문제 요약 30장 요청 인증 30.1 서론 30.1.1 근원 30.1.2 무결성 30.1.3 부인봉쇄 30.2 개괄 30.3 구현 30.3.1 자격증명 생성 30.3.2 등록과 자격증명 교환 30.3.3 로우 서명 생성 및 검증 30.3.4 요청 핑거프린팅 30.3.5 서명 포함 30.3.6 요청 인증 30.3.7 최종 API 정의 30.4 트레이드오프 30.5 연습문제 요약 찾아보기

1. "일관성"을 확보하라 - API 설계 혼돈에서 벗어나는 핵심 API 설계에서 가장 큰 문제는 일관성의 부재다. 같은 팀, 같은 회사에서 만든 API조차 서로 다른 명명 규칙, 다른 에러 처리 방식, 다른 데이터 구조를 사용하며 개발자들을 혼란에 빠뜨린다. 『웹 개발자를 위한 API 디자인 패턴』은 이름 붙이기부터 리소스 계층 구조, 데이터 타입과 기본값까지 API 설계의 모든 요소에 일관된 원칙을 제시한다. RESTful API든 RPC든, 소규모 서비스든 대규모 플랫폼이든 반드시 일관성 있는 설계 패턴을 따라야만 한다. 이 책은 임시방편적인 API 설계를 넘어서 실제 확장 가능한 'API 설계' 전쟁이 어떻게 가능한지 안내해 줄 것이다. 2. 실전에 강해져라 - 패턴을 "실제 코드"로 바꾸는 방법 이 책은 단순한 설계 원칙을 넘어, API 개발 과정에서 마주하는 모든 실무적 문제를 구체적인 패턴으로 해결하는 방법과 노하우를 제공한다. 또한 TypeScript 중심의 명확한 코드 예제, 체계적인 검증 절차, 리소스 관계와 보안 구현에 대한 단계별 접근법으로 실질적인 문제 해결 실력까지 갖추게 해준다. API를 제대로 설계하고 싶다면, 단순히 기능만 구현하는 차원을 넘어 확장 가능하고 유지보수 가능한 구조를 만드는 방법을 이 책에서 배울 수 있다. 게다가 구글의 실제 사례와 폭넓은 패턴 예제를 추가해, 책을 읽는 누구나 '내 프로젝트에 바로 적용할 수 있다'는 자신감을 안겨줄 것이다. 3. 설계가 전략이 되는 전쟁 - 임시방편을 넘어 '확장 가능한 아키텍처'에 집중하라 이 책은 'API 설계를 전략으로, 그리고 실질적인 비즈니스 가치로 연결해주는 것'에 진심을 다한다. 또한 설계 결과를 실제 서비스 확장·팀 협업·장기 유지보수 정책에 녹여낼 수 있는 실전적 접근법을 제시한다. 이 책은 단순 기능 구현을 뛰어넘어, 전략적으로 리소스 모델링, 버전 관리, 보안 정책까지 실제로 적용하는 방법을 알려주며, 이에 더해 장기 실행 작업과 배치 처리, 그리고 복잡한 데이터 관계를 현명하게 다루는 노하우까지 제공한다. API가 곧 비즈니스 성공의 핵심 인프라임을 아는 이들에게 강력 추천하고 싶은 실전형 무기다. API 설계라는 피할 수 없는 난제를 체계적인 패턴과 실전 전략으로 돌파하고 싶은 개발자라면, 지금 이 책을 선택하길 바란다. ◈ 이 책의 대상 독자 ◈ 웹 API, 특히 대중에 공개할 API를 만들고 있거나 만들 예정인 모든 독자를 대상으로 하는 책이다. 직렬화 포맷(예: JSON, 구글 프로토콜 버퍼, Apache Thrift)이나 일반적인 스토리지 패러다임(예: 관계형 데이터베이스 스키마)에 익숙하다면 도움이 되겠지만, 필수적인 것은 아니다. 또한 HTTP 및 관련한 여러 메서드(예: GET, POST)는 이 책 전반에 걸쳐 예제 내의 전송 방식으로 자주 등장하기 때문에 알고 있는 것이 이해에 더 유리하다. API를 디자인하면서 문제를 마주하고 “어딘가 이 문제를 해결하는 방법이 있을 텐데”라고 생각해 본 적이 있다면 이 책은 당신을 위한 것이다. ◈ 이 책의 구성 ◈ 이 책은 6개의 부로 구성돼 있다. 처음 2개의 부는 API 디자인에 관한 좀 더 일반적인 주제를, 나머지 4개의 부는 각 디자인 패턴에 대한 세부를 다룬다. 1부, 서론에서는 책의 나머지 부분에 관한 개괄과, 웹 API와 나중에 웹 API에 적용할 디자인 패턴의 정의 및 평가 프레임워크를 살펴본다. ● 1장, API 소개에서는 API가 무엇을 뜻하는지와 왜 API가 중요한지를 다룬다. 아울러 API가 얼마나 좋은지를 평가할 수 있는 프레임워크를 제시한다. ● 2장, API 디자인 패턴 소개에서는 1장에서 더 나아가, API에 디자인 패턴을 적용하는 방법과 왜 디자인 패턴이 유용한지를 다룬다. 이를 위해 API 디자인 패턴의 내부 구조를 분석하고, 디자인 패턴을 사용해 API를 개선하는 간단한 예를 보여준다. 2부, 디자인 원칙에서는 1부의 내용을 기반으로 해서 API를 제작할 때 고려해야 할 몇 가지 일반적인 디자인 원칙을 다룬다. ● 3장, 이름 붙이기에서는 API에서 이름을 붙여야 하는 여러 가지 구성 요소를 살펴보고, 이름을 선택할 때 무엇을 고려해야 할지 다룬다. 아울러 이름 붙이기가 단순히 피상적인 차원을 떠나 높은 중요성을 갖는 이유를 설명한다. ● 4장, 리소스 범위와 계층에서는 여러 리소스가 서로 관계를 갖는, 좀 더 규모가 큰 API를 다룬다. 리소스와 그 관계를 어떻게 결정해야 할지에 관한 몇 가지 질문을 던진 후 이 과정에서 피해야 할 점들을 예를 통해 살펴본다. ● 5장, 데이터 타입과 기본값에서는 API 내의 다양한 데이터 타입과 그 기본값을 사용하는 방법을 다룬다. 가장 흔히 쓰이는 문자열이나 숫자 값뿐만 아니라, 맵이나 리스트 등의 복잡한 타입도 함께 살펴본다. 3부, 기초 패턴부터는 본격적으로 디자인 패턴을 살펴본다. 우선 대부분의 API에 적용해야 하는 기초 패턴부터 시작한다. ● 6장, 리소스 식별에서는 API 사용자가 리소스를 식별하는 방법을 알아본다. 묘석화(tombstoning), 문자열 세트, 인코딩 등 로우레벨 세부 사항까지 모두 살펴보며, 체크섬을 통해 ID가 누락된 것인지 유효하지 않은지 구분하는 방법도 다룬다. ● 7장, 표준 메서드에서는 웹 API의 여러 표준 메서드(get, list, create, update, delete)가 작동하는 방법을 알아본다. 또한 각 표준 메서드가 모든 리소스에 대해 동일한 방식으로 작동해야 하며, 각 리소스마다 그 특성에 따라 차이를 보이면 안 되는 이유를 설명한다. ● 8장, 부분 업데이트와 부분 취득에서는 표준 메서드 중 2가지(get, update)를 확장해서 사용자가 리소스 중 일부에 대해서만 상호작용하는 방법을 알아본다. 아울러 이 방법이 (사용자와 API 양측에) 왜 필요하고 유용한지, 그리고 기존 시스템에 대한 개입을 최소화하면서 이 기능을 구현하려면 어떻게 해야 하는지 알아본다. ● 9장, 사용자 메서드에서는 기존 표준 메서드 대신 API 내에서 원하는 기능을 사용자 메서드로 구현하는 방법을 알아본다. 특히 사용자 메서드가 가능한(혹은 가능하지 않은) 상황이 언제인지와, API 내에서 가능 여부를 어떻게 결정해야 하는지 살펴본다. ● 10장, 장기 실행 작업에서는 API 메서드가 즉각적으로 동작하면 안 되는 특수한 상황과, 이 상황을 편리하게 다룰 수 있는 장기 실행 작업(LRO, Long-Running Operation)을 알아본다. LRO가 어떻게 작동하는지, LRO가 지원하는 메서드(일시정지, 재개, 취소)가 어떻게 이뤄지는지도 살펴본다. ● 11장, 재수행 가능 작업에서는 어떤 작업을 반복해서 실행하는, 마치 웹 API상에서 cron 작업을 수행하는 개념을 다룬다. 익스큐션(Execution) 리소스를 사용하는 방법과, 이를 스케줄에 따라 또는 원하는 시점에 실행하는 방법을 알아본다. 4부, 리소스 관계에서는 리소스와 리소스 간의 관계에 집중한다. 4장의 내용을 좀 더 상세히 설명하는 셈이다. ● 12장, 싱글톤 서브리소스에서는 작은 크기의, 관계를 이루면서 격리된 데이터를 싱글톤 서브리소스로 분리하는 방법을 설명한다. 특히 이 방식을 적용하는 것이 적절하거나 적절하지 않은 경우가 언제인지 살펴본다. ● 13장, 교차 참조에서는 웹 API에서 리소스가 다른 리소스의 참조를 참조 포인터나 인라인 값으로 저장하는 방법을 개괄한다. 아울러 캐스케이드 삭제나 시간에 따라 변경된 데이터를 업데이트하는 등의 특수한 상황에 대응하는 방법도 살펴본다. ● 14장, 연관 리소스에서는 리소스 간의 일대일 관계를 확장해서 연관 리소스를 통해 다대다 관계를 나타내는 방법을 설명한다. 또한 이들 관계를 메타데이터로 어떻게 저장할 수 있을지 다룬다. ● 15장, add 및 remove 사용자 메서드에서는 다대다 관계를 다룸에 있어 연관 리소스 대신 add 및 remove 등의 메서드로 간편하게 수행하는 방법을 다룬다. 아울러 이들 메서드의 트레이드오프와, 왜 이 방식이 항상 잘 들어맞는 것은 아닌지 살펴본다. ● 16장, 다형성에서는 다형성, 즉 변수가 다양한 타입에 대응할 수 있게 하는 개념을 살펴본다. API 리소스 내의 다형성 필드를 다루는 방법과, 다형성 메서드 사용을 피해야 하는 이유를 설명한다. 5부, 선택적 작업에서는 단일 API 리소스의 상호작용을 넘어서 전체 리소스 컬렉션에서의 상호작용에 대한 디자인 패턴을 살펴본다. ● 17장, 복사와 이동에서는 API 내에서 리소스를 복사하거나 이동하는 방법을 설명한다. 외부 데이터를 다루거나, 서로 다른 부모 리소스에서 메타데이터를 상속하거나, 자식 리소스를 다루는 방법 등 다소 복잡한 문제를 해결한다. ● 18장, 배치 작업에서는 표준 메서드(get, create, update, delete)를 단일 리소스가 아닌 컬렉션에 동시에 작업하는 방법을 알아본다. 또한 그 작업 결과를 반환받는 방법이나 부분적 실패를 다루는 방법 등 까다로운 문제도 살펴본다. ● 19장, 기준 기반 삭제에서는 18장의 배치 delete 메서드를 확장해서 특정 리소스가 아닌 필터 조건에 맞는 모든 리소스를 제거하는 방법을 다룬다. 또한 일관성 문제를 해결하는 방법과, 의도치 않은 데이터 파괴를 피하는 규범을 살펴본다. ● 20장, 익명 기록에서는 직접적으로 지시할 수 없는 비리소스 데이터를 입력하는 방법을 자세히 들여다본다. 익명으로 데이터를 작성하는 방식과, 이러한 익명 데이터 입력의 일관성과 API에 적합한지를 판단하는 트레이드오프를 살펴본다. ● 21장, 페이징에서는 페이징을 통해 큰 규모의 데이터 세트를, 불투명 토큰을 사용해 오고가는 식으로 브라우징하는 방법을 설명한다. 아울러 커다란 단일 리소스 내에서도 페이징을 구현하는 방법을 살펴본다. ● 22장, 필터링에서는 필터 기준을 적용해 리소스 목록을 나타내는 방법과, API에서 필터를 가장 잘 표현하는 방법을 다룬다. 이 내용은 19장에서 다룬 주제와 직접적으로 연관된다. ● 23장, 가져오기와 내보내기에서는 리소스를 API 안팎으로 가져오고 내보내는 방법을 다룬다. 아울러 이들 동작이 백업 및 복원과 어떤 맥락의 차이를 보이는지도 살펴본다. 6부, 안전과 보안에서는 다소 지루할 수도 있는 주제인, API의 안전성과 보안에 관해 살펴본다. API를 공격자로부터 안전할 수 있게 하는 방법과 더불어, 사용자 자신의 실수로부터 보호하는 API 메서드를 제시한다. ● 24장, 버전 작성과 호환성에서는 버전 작성과 다른 버전 간의 호환성이 갖는 의미를 다룬다. 호환성을 일종의 스펙트럼 개념으로 접근해서 API 전체에 걸쳐 일관적으로 호환성 정책을 정의하는 것의 중요성을 알아본다. ● 25장, 논리 삭제에서는 사용자 자신의 실수를 보호할 수 있는 패턴(논리 삭제)을 제시한다. 즉, 리소스를 보이지 않게 제거하되, 완전히 시스템에서는 삭제되지 않게 한다. ● 26장, 요청 중복 방지에서는 요청 식별자를 사용해 시스템에서의 중복 동작 방지를 시도한다. 이 과정에서 요청 ID를 사용하는 것의 어려움과, 큰 스케일의 시스템에서 ID가 제대로 다뤄지는지 확인하는 알고리듬을 살펴본다. ● 27장, 요청 검증에서는 요청을 검증해 사용자가 실제 작업을 실행하지 않고도 동작 결과를 미리 보기 할 수 있는 방법을 다룬다. 아울러 실제 요청과 검증 요청 각각의 부수 효과 등 좀 더 복잡한 문제를 살펴본다. ● 28장, 리소스 리비전에서는 시간에 따른 변화를 추적하는 리소스 리비전을 소개한다. 이전 리비전을 복원하는 등의 기본적인 작업과, 계층 내의 자식 리소스에 리비전을 적용하는 등의 고급 주제를 살펴본다. ● 29장, 요청 재시도에서는 사용자에게 API 요청 재시도가 필요함을 알리는 패턴을 소개한다. 아울러 여러 종류의 HTTP 응답 코드 및 각각이 재시도에 안전한지의 여부를 제시한다. ● 30장, 요청 인증에서는 각 요청의 인증과 API가 사용자를 인증할 때 고려해야 할 여러 보안 기준을 살펴본다. API 요청을 디지털 서명함으로써 근원과 무결성을 입증 가능하게 하며, 이후 부인될 가능성을 방지하는 방식을 소개한다. ◈ 옮긴이의 말 ◈ 저자가 주도적으로 참여했던 aip.dev 사이트 소개글에서처럼 API를 디자인한다는 것은 결국 어떤 결정을 내리는 것입니다. 복잡한 기능을 어떻게 쉽고 간단하게 사용할 수 있도록 추상화해야 할까? 어느 수준까지 인터페이스를 바깥에 열어야 할까? 편리성과 유연함과 보안 간의 트레이드오프를 어떻게 따져야 할까? 혹은 지금 내린 이 결정을 나중에 바꿔야 할 수도 있을까? 누군가가 만든 API를 사용하면서 그들이 매 순간 마주했던 고민을 어렴풋이나마 가늠할 수 있었습니다. 이 책은 웹 API라는 기존의 전통적인 애플리케이션과 다른 성격을 갖는 API를 우리가 어떻게 다뤄야 할지를 기초부터 시작해 그 실마리를 제공합니다. 오랜 경력과 실무 경험을 녹여냈기 때문에, 그리고 시간이 지나 기술이 발전해도 크게 변하지 않을 디자인 패턴들을 추려냈기 때문에 곁에 두고 막힐 때마다 한 번씩 꺼내보면서 많은 도움을 받을 수 있는 책이라고 믿습니다. 이 책이 독자에게 많은 도움을 줄 수 있도록 나름 최선을 다해 번역했으나 부족한 부분이 있을 수 있습니다. 어색한 부분이나 더 적절한 제안이 있다면 이메일 등으로 피드백 주시기를 부탁드립니다.