Tôi đã đánh giá một số versioning schemas cho apis REST (tiêu đề, url, ...). Cho đến nay, cách tiếp cận đáng tin cậy nhất dường như là tùy chọn url: Nó hoạt động với proxy và không dựa vào các lược đồ tối nghĩa như dates for versioning.Phiên bản ngữ nghĩa của REST apis?
Bây giờ, khi tôi nhìn xung quanh, mọi người sử dụng phương pháp tiếp cận dựa trên url dường như sử dụng các phiên bản như v1, v2, v.v. Không ai sử dụng các phiên bản nhỏ, hoặc thậm chí một lược đồ như semantic versioning.
Điều này đặt ra một số câu hỏi:
- Khi nào bạn tăng số phiên bản của một api REST (chắc chắn, bạn có nhiều bản cập nhật cho nó hơn là chỉ một lần trong năm năm)?
- Nếu bạn chỉ có một bản vá lỗi, bạn có thể không tăng số phiên bản, nhưng làm thế nào để bạn khác nhau cả hai phiên bản?
- Nếu bạn sử dụng một cách tiếp cận rất tinh dạng hạt, bạn kết thúc với rất nhiều của phiên bản bạn cần phải lưu trữ song song. Làm thế nào để bạn xử lý đó?
Nói cách khác: Làm thế nào để một công ty như GitHub, ví dụ: chỉ thực hiện v3 hôm nay (2015), khi họ ở trong doanh nghiệp đã 7 năm rồi? Điều đó có nghĩa là họ thực sự chỉ thay đổi api của họ hai lần? Tôi khó có thể tin được điều đó.
Bất kỳ gợi ý?
Trên thực tế đó là số phiên bản lớn. Tôi nghĩ rằng phiên bản tài nguyên quan trọng hơn nhiều, nhưng không ai nói về nó. – inf3rno
Bạn có thể giải thích thêm một chút về ý nghĩa của phiên bản * tài nguyên * không? –
ofc. khi một tài nguyên thay đổi, nó phải thay đổi số phiên bản. Bằng cách cập nhật một máy khách, nó phải gửi số phiên bản của đại diện tài nguyên được lưu trữ cục bộ cùng với yêu cầu, và vì vậy dịch vụ sẽ biết liệu nó có phiên bản mới của tài nguyên hay không.Mọi người gọi etag này, nhưng nếu bạn có tài nguyên hoặc phản hồi với nhiều tài nguyên, bạn không thể gửi nhiều tiêu đề etag (afaik), vì vậy bạn phải gửi số phiên bản trong phần thân. – inf3rno