Bạn phiên bản hoá API kiểu gì, và một thay đổi thế nào thì gọi là phá vỡ tương thích?

Điều đáng nói nhất là chi phí thật của phiên bản hoá không nằm ở việc phát hành v2 — nó nằm ở việc BẢO TRÌ v1 song song trong nhiều năm. Mỗi bản vá bảo mật phải áp cho cả hai, mỗi thay đổi database phải tương thích với cả hai, và đội của bạn phải nhớ cả hai hoạt động thế nào. Vì vậy chiến lược tốt nhất thường là tránh cần v2: thiết kế để mở rộng được, và coi mỗi lần buộc phải lên phiên bản là một thất bại nhỏ của thiết kế trước đó.

Cách tiếp cận của Stripe đáng học vì nó tách hai thứ mà mọi người hay gộp: phiên bản là của TÀI KHOẢN chứ không của lời gọi. Client được ghim vào phiên bản tại thời điểm họ tích hợp, và server chạy một chuỗi hàm chuyển đổi để hạ cấp phản hồi mới về hình dạng cũ. Nhờ vậy chỉ có một đường code nghiệp vụ, phần tương thích nằm gọn ở biên. Đắt để dựng, nhưng nó là cách duy nhất mình biết để duy trì hàng chục phiên bản mà không phát điên.

Về “thêm trường không phá vỡ”: điều này chỉ đúng nếu client thật sự bỏ qua trường lạ, và nhiều client thì không — bộ giải mã nghiêm ngặt sẽ ném lỗi. Vì thế nên ghi rõ trong tài liệu rằng client PHẢI chấp nhận trường chưa biết, và tốt hơn nữa là kiểm chứng điều đó bằng test tương thích chứ không chỉ bằng lời hứa.