-
Stripe API 버전 관리, 작동 방식과 따라 할 점
Stripe API 버전 관리는 계정마다 날짜 기반 버전을 고정하고 요청마다 헤더로 덮어쓸 수 있게 한다. 작동 방식과 유지 비용, 작은 API가 따라 할 점을 설명한다.
API 변경5분 분량
-
Protobuf 브레이킹 체인지: 와이어에서 살아남는 것
Protobuf 파괴적 변경은 URL이 아니라 와이어 위에서 일어난다. 어떤 gRPC 필드 변경은 공짜지만 다른 변경은 모든 클라이언트를 조용히 망가뜨린다.
API 변경5분 분량
-
버전 번호 없는 GraphQL 비추천 처리
GraphQL은 URL에 v1이나 v2가 없고 필드를 지시어로 하나씩 비추천 처리한다. 이는 체인지로그가 지는 책임을 바꾼다. 파괴적 변경과 안전한 제거법을 다룬다.
API 변경4분 분량
-
API 마이그레이션 가이드는 어떻게 작성하는가
API 마이그레이션 가이드는 호환되지 않는 변경을 장애가 아니라 체크리스트로 바꾼다. 무엇이 필요한지, 언제 써야 하는지, 왜 항목 하나로는 부족한지 설명한다.
API 변경4분 분량
-
내부용 API 체인지로그: 다른 팀에게 무엇이 달라지는가
공개 API 체인지로그에는 직접 연락할 수 없는 독자가 있고, 내부용에는 두 층 떨어진 독자가 있다. 이 차이가 체인지로그의 책임을 어떻게 바꾸는지 짚어본다.
API 변경4분 분량
-
웹훅 체인지로그, 아무도 요청하지 않은 파괴적 변경
웹훅 페이로드 변경은 새 형태를 거부할 호출자가 없어 조용히 깨진다. 무엇이 파괴적 변경인지와 버전을 매기는 방법을 다룬다.
API 변경4분 분량
-
API Sunset 헤더, 언제 보내야 하는가
API Sunset 헤더는 비추천 공지와 달리 클라이언트에 버전이 응답을 멈춘다고 알린다. RFC 8594가 다루는 범위와 브라운아웃의 이점을 설명한다.
API 변경4분 분량
-
API 체인지로그: 무엇을 공개하고 누가 읽는가
API 체인지로그는 내 코드가 다음 달에도 작동할지 판단하려는 사람이 읽는다. 각 항목이 독자에게 져야 할 책임과 위치, 구독 방법을 설명한다.
API 변경5분 분량
-
개발자를 잃지 않고 API를 비추천 처리하는 방법
비추천 처리는 날짜가 적힌 하나의 약속이다. 일정, 공지 템플릿, 응답 헤더, 서비스 종료가 사고로 번지지 않게 막는 한 단계를 설명한다.
API 변경5분 분량
-
호출자를 위한 API 버저닝 모범 사례
부서지는 것만 버전으로 관리하고, 호출자가 볼 수 있는 곳에 버전을 두며, 예전 버전은 정해진 날짜까지 유지하자. 네 가지 방식을 비교한다.
API 변경6분 분량
-
파괴적 변경: 무엇이 해당하고 어떻게 출시하는가
파괴적 변경은 올바른 호출자가 버티지 못하는 변경이다. 해당 여부, CI에서 잡는 법, 안전하게 출시하는 방법을 정리한다.
API 변경7분 분량