[Ban topic] Thiết kế API có nhiều version

[cowo (cowo Hari)]

Xin chào,
Cho em hỏi API có nhiều version thì khi version mới ra mắt thì API thuộc version cũ có còn sử dụng được không ?
VD : daynhauhoc nâng cấp API lên version 3 https://daynhauhoc.com/api/v3/topic/123
thì API thuộc version cũ https://daynhauhoc.com/api/v1/topic/123 có còn gọi được không ? nên giữ lại hay là xóa luôn.
Nếu các version sau cập nhật có chỉnh sửa bảng trong database (xóa trường, sửa kiểu dữ liệu,sửa tên cột,…) thì làm sao không ảnh hưởng đến những tính năng đã làm xong trước đó ? Thường người ta mở rộng database bằng cách nào ? VD : thêm bảng vào database có sẵn, append thêm cột vào bảng có sẵn phải không ?
Thanks

[library (La biblioteca)]

@cowo

Cho em hỏi API có nhiều version thì khi version mới ra mắt thì API thuộc version cũ có còn sử dụng được không ?

Tất nhiên là có chứ cậu Backward-compatibility luôn là thứ cần phải cân nhắc khi design mà
Việc giữ API version cũ hơn nhằm support cho các client vẫn đang sử dụng version cũ, như các thiết bị cũ chưa update, hoặc các client chưa migrate thành công sang version mới.

Các API version cũ hơn sẽ luôn được giữ lại, trừ khi:

• Cậu chắc chắn không có bất kỳ ai gọi tới API version đó.
• Cậu biết nó có thể gây thiệt hại lớn, nhưng công ty/sếp cậu có thể chịu được tổn thất đó.

@cowo

Nếu các version sau cập nhật có chỉnh sửa bảng trong database (xóa trường, sửa kiểu dữ liệu,sửa tên cột,…) thì làm sao không ảnh hưởng đến những tính năng đã làm xong trước đó ?

Một lần nữa, backward-compatibility luôn được cân nhắc khi cậu thiết kế API. Việc thay đổi database schema mà ảnh hưởng tới các client khác luôn không phải là solution.
Nếu như cậu phải làm việc với các domain cần thay đổi các trường thường xuyên (trong TH sửa đổi trường/xóa trường. TH thêm trường mới sẽ dễ dàng hơn nhiều và thường không phải vấn đề lớn), cậu có thể cân nhắc design API của cậu sử dụng hoặc noSQL, hoặc cậu sẽ có xu hướng tạo các trường mới có kiểu tương đối generic như varchar, để hạn chế việc sửa đổi.

Tớ sẽ chỉ cho cậu 1 số tip khi cậu phải deal với vụ backward compatibility này, theo các TH:

• Nếu cậu cần thêm trường mới: Cậu chỉ cần add thêm cột mới thôi. Việc này có thể làm on-the-fly với một số RDBS, với cost tương đối dễ chịu.
  Sau đó, cậu có thể deploy application mới (sử dụng field mà cậu mới add ở chỗ cần thiết).
• Nếu cậu cần xóa 1 trường đi: nah, cậu sẽ không làm thế. Cậu chỉ đơn giản sửa lại application logic, loại bỏ sự hiện diện của trường đó tại nơi mà cậu không muốn. Vậy thôi
• Nếu cậu cần thay đổi trên kiểu dữ liệu: Sẽ có một số kiểu dữ liệu cậu có thể thay đổi, như việc tăng kích thước cho varchar chẳng hạn. Nếu đó là trường được index, cậu có thể gặp một số vấn đề về performance.
  Nhưng nếu cậu cần đổi 1 phát, chẳng hạn từ int sang varchar, he he, cậu giao nó cho tay nào design 1 trường như vậy. Hoặc đuổi việc hắn đi
• Nếu cậu cần sửa tên cột: bảo với người assign task đó cho cậu: cố chịu đi, tên xấu còn hơn tốn một đống tiền để rename 1 cái tên ngớ ngẩn do ai đó đặt ra.

Hope it helps!

EDIT: @cowo tớ có thêm một số chiến lược khi cậu cân nhắc chỉnh sửa DB. Hi vọng nó sẽ giúp cậu nhiều hơn.