search

caffeine-library / release-everything

'Release의 모든 것'을 읽는 스터디
3 stars 0 forks source link

[keyword] 14장 - 버전 관리 #40

Closed kth990303 closed 7 months ago

kth990303 commented 7 months ago

주제

'14장 - 버전 관리'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

39

@caffeine-library/readers-release-everything

leejaeseung commented 7 months ago

14.1.1 호환되는 API 변경

생성형 테스트 : 무작위 케이스를 생성해 테스트하는 기법? 이를 실제 서비스 API 를 호출해 테스트해보라는 의미 같다. (외부 호출 테스트) (혹은 테스트용 Mock 서버를 관리해서 Mock 서버의 요청 및 응답 값을 조절해서 테스트하는 방식도 있는 것 같다.)

외부 호출가 있으면 외부 API 의 변경을 금방 감지할 수 있다. 하지만 이는 외부 API 서버가 우리 팀과 협업을 원활하게 하는 경우에 가능할 것 같다. (계정 API 같은 경우는 한 팀 한 팀 신경 쓸 겨를이 있을까?)

나중에는 외부 호출 대신 요청/응답에 대한 테스트 코드를 나누어서 외부 의존성을 격리하는 테스트 방식이 나온다. mocking 과 통합 테스트를 적절히 섞어놓은 듯.

14.1.2 호환성을 깨는 API 버전 변경

API 버전을 변경할 때 할 수 있는 방법들

  1. URL 에 접두사나 질의 매개변수로 버전 식별 문자를 추가한다.
  2. GET 요청에 Accept 헤더를 사용해서 희망하는 버전을 나타낸다.
  3. 애플리케이션 고유 헤더를 사용해 버전을 나타낸다.
  4. POST, PATCH 요청 본문에 버전을 나타내는 필드를 추가한다.

1번 URL 에 v1, v2 등의 접두사를 넣어 버전을 명시하는 방식이 가장 나은 듯 하다. 버전이 변경된다는 건 이전 버전을 deprecate 해야 한다는 건데, 이전 버전을 손쉽게 제거할 수 있어야 한다. 버전 정보를 숨겨놓는다면 deprecate 작업이 쉽지 않을 듯.. 그리고 가장 명시적이다. API 에 관해 논의할 때 URL 만으로 쉽게 커뮤니케이션이 가능하다.

binchoo commented 7 months ago

포스텔 법칙 기존에 작동하던 합의가 계속 동작하려면 (하위 호환성) 받아들이는 범위는 넓고, 보내주는 범위는 좁아야 한다는 법칙입니다. API를 이용하고 있는 수만의 클라에게 변경을 강제해서는 안 되며 API와 데이터 스키마 역시 소스코드 처럼 버저닝이 필요하다는 내용으로 이어집니다.

  1. 받아들이는 것에 관대하여라

    • 서버는 보다 많은 요청을 처리할 수 있다.
    • 더 많은 매개변수
    • 더 많은 데이터 필드
    • 이유없이 보내진 빈 배열
    • 클라는 보다 많은 응답을 수신할 수 있다.
    • 더 많은 데이터 필드

  2. 보내는 것에 깐깐하여라

    • 서버는 기존보다 더 작게 응답할 수 없다.
    • 더 적은 데이터 필드
    • 지원 프로토콜 제거
    • 클라는 기존보다 덜 요청할 수 없다.

한 때, API 변경으로 응답 데이터가 작아지면 성능상 좋은거 아닌가 싶었는데요. 메타 같은 큰 벤더 입장에서, 지속 가능한 API는 무중단 배포 뿐만 아니라 하위 호환성도 큰 영향을 미치겠구나 알게 되었습니다.