Cộng đồng phát triển phần mềm đang tích cực thảo luận về một trong những nguyên tắc cơ bản nhất trong thiết kế API: quy tắc thiêng liêng không bao giờ phá vỡ userspace. Nguyên tắc này, được người tạo ra Linux Linus Torvalds ủng hộ mạnh mẽ, đã trở thành nền tảng của tính ổn định API nhưng cũng đặt ra câu hỏi về sự cân bằng giữa độ tin cậy và đổi mới.
Bản Chất Hai Mặt Của Tính Ổn Định API
Trong khi nguyên tắc không bao giờ phá vỡ userspace bảo vệ người dùng cuối khỏi phần mềm bị lỗi, các nhà phát triển chỉ ra rằng nó chỉ kể một nửa câu chuyện. Kernel Linux duy trì khả năng tương thích ngược nghiêm ngặt cho các giao diện hướng người dùng, nhưng tự do phá vỡ các API kernel nội bộ mà không cảnh báo. Cách tiếp cận này làm nổi bật một sự phân biệt quan trọng trong thiết kế API: không phải tất cả giao diện đều cần cùng mức độ đảm bảo ổn định.
Cuộc thảo luận cộng đồng cho thấy rằng việc tuyên bố trước những gì ổn định quan trọng hơn các lời hứa ổn định chung chung. Điều này cho phép các nhà phát triển đổi mới trong các lĩnh vực được đánh dấu là không ổn định trong khi duy trì độ tin cậy vững chắc ở những nơi quan trọng nhất.
Triết lý API của Linux Kernel
- API Userspace: Không bao giờ bị phá vỡ, được duy trì vô thời hạn để đảm bảo khả năng tương thích ngược
- API Kernel: Có thể bị phá vỡ mà không cần cảnh báo, cho phép đổi mới nội bộ
- Nguyên tắc chính: Tuyên bố rõ ràng những gì ổn định ngay từ đầu, duy trì nghiêm ngặt những cam kết đó
Thách Thức Tương Thích Của GNU libc
Bất chấp cam kết của kernel về tính ổn định userspace, thư viện GNU C ( glibc ) đặt ra những thách thức tương thích liên tục. Các chương trình được biên dịch với các phiên bản mới hơn của glibc thường không chạy được trên các hệ thống cũ hơn, buộc mọi thứ phải được nâng cấp cùng nhau. Điều này tạo ra rào cản thực tế đối với các nỗ lực ổn định của kernel.
Ngay cả khi kernel không phá vỡ userspace, GNU libc vẫn làm điều đó, liên tục, vì vậy hiệu ứng ròng là userspace Linux bị hỏng bất kể những nỗ lực của các nhà duy trì kernel.
Liên kết tĩnh cung cấp một giải pháp, mang lại tính ổn định đáng kinh ngạc cho các tệp thực thi. Tuy nhiên, các hạn chế cấp phép với GNU libc khiến cách tiếp cận này trở nên có vấn đề đối với nhiều ứng dụng thương mại, dẫn đến việc một số nhà phát triển khám phá các lựa chọn thay thế như musl libc hoặc dự án LLVM libc đang nổi lên.
Vấn đề tương thích GNU libc
- Các chương trình được biên dịch trên phiên bản libc mới hơn không thể chạy trên các hệ thống cũ hơn
- Yêu cầu nâng cấp đồng bộ trên toàn bộ hệ thống
- Liên kết tĩnh với GNU libc có các hạn chế giấy phép LGPL đối với phần mềm độc quyền
- Các giải pháp thay thế: musl libc (giấy phép linh hoạt hơn), LLVM libc (đang trong quá trình phát triển)
Phiên Bản API: Điều Ác Cần Thiết Hay Lỗi Thiết Kế?
Cuộc tranh luận mở rộng đến các chiến lược phiên bản API, với các nhà phát triển chia sẻ những trải nghiệm hỗn hợp về các sơ đồ phiên bản dựa trên URL. Nhiều người báo cáo rằng hầu hết các API không bao giờ tiến xa hơn phiên bản 1, khiến tiền tố /v1 phần lớn mang tính nghi lễ. Khi các thay đổi phá vỡ xảy ra, các nhóm thường tạo ra các endpoint hoàn toàn mới với tên khác nhau thay vì tăng số phiên bản.
Một số nhà phát triển ủng hộ việc bao gồm số phiên bản từ đầu để dễ dàng chuyển đổi trong tương lai, trong khi những người khác lập luận rằng điều này khuyến khích những thay đổi phá vỡ không cần thiết. Cuộc thảo luận cho thấy rằng phiên bản thành công đòi hỏi lập kế hoạch cẩn thận và chi phí bảo trì đáng kể, vì mỗi phiên bản nhân lên gánh nặng kiểm tra và hỗ trợ.
Các Mẫu Hình Phiên Bản API Được Quan Sát
- v1: Phiên bản phổ biến nhất, thường là phiên bản duy nhất được phát hành
- v2: Hiếm gặp, thường đại diện cho việc thiết kế lại theo hướng "giờ chúng ta đã biết mình đang làm gì"
- v3: Phổ biến hơn v2, thường xuất hiện nhanh chóng sau v2
- v4+: Cực kỳ hiếm gặp trong thực tế
- Phương pháp thay thế: Các endpoint mới với tên mô tả thay vì số phiên bản
Tính Đơn Giản Xác Thực So Với Bảo Mật
Một chủ đề đặc biệt gây tranh cãi nổi lên xung quanh các phương pháp xác thực API. Trong khi OAuth và các sơ đồ xác thực tinh vi khác cung cấp bảo mật tốt hơn, nhiều nhà phát triển lập luận để hỗ trợ các khóa API đơn giản nhằm giảm rào cản gia nhập. Điều này phản ánh một căng thẳng rộng lớn hơn giữa các thực hành tốt nhất về bảo mật và trải nghiệm nhà phát triển.
Cộng đồng nhấn mạnh rằng nhiều người dùng API không phải là kỹ sư phần mềm chuyên nghiệp mà là nhân viên bán hàng, sinh viên, hoặc những người có sở thích cần truy cập nhanh cho các script đơn giản. Các luồng xác thực phức tạp có thể ngăn những người dùng này bắt đầu, có khả năng hạn chế việc áp dụng và tính hữu ích của API.
Chi Phí Của Những Thay Đổi Phá Vỡ
Những trải nghiệm thực tế được chia sẻ trong cuộc thảo luận làm nổi bật những tác động lan tỏa của các thay đổi API. Các nhà phát triển mô tả những sự cố mà các tích hợp bên thứ ba gây ra lỗi hệ thống thông qua các mẫu sử dụng không mong đợi, và cách một thay đổi API bất cẩn có thể phá vỡ hàng trăm hoặc hàng nghìn ứng dụng downstream.
Điều này củng cố lý do tại sao nguyên tắc không bao giờ phá vỡ userspace tồn tại: bản chất kết nối của phần mềm hiện đại có nghĩa là các nhà duy trì API có trách nhiệm với toàn bộ hệ sinh thái của họ, không chỉ những người dùng trực tiếp.
Tham khảo: Everything I know about good API design