Thông thường, người ta có nên phát triển thư viện máy khách cho các dịch vụ REST để giúp ngăn chặn sự phá vỡ API không?

Chúng tôi có một dự án trong đó mã UI sẽ được phát triển bởi cùng một nhóm nhưng bằng ngôn ngữ khác (Python / Django) từ lớp dịch vụ (REST / Java). Mã cho mỗi lớp thoát trong các kho mã khác nhau và có thể theo các chu kỳ phát hành khác nhau. Tôi đang cố gắng đưa ra một quy trình sẽ ngăn chặn / giảm các thay đổi phá vỡ trong lớp dịch vụ theo quan điểm của lớp UI.

Tôi đã nghĩ sẽ viết các bài kiểm tra tích hợp ở cấp lớp UI mà chúng tôi sẽ chạy bất cứ khi nào chúng tôi xây dựng giao diện người dùng hoặc lớp dịch vụ (chúng tôi đang sử dụng Jenkins làm công cụ CI của chúng tôi để xây dựng mã trong hai repos Git) và nếu có những thất bại sau đó một cái gì đó trong lớp dịch vụ bị phá vỡ và cam kết không được chấp nhận.

Sẽ là một ý tưởng tốt (đó có phải là một cách thực hành tốt nhất không?) Để nhà phát triển lớp dịch vụ tạo và duy trì thư viện máy khách cho dịch vụ REST tồn tại trong lớp UI mà họ sẽ cập nhật mỗi khi có sự thay đổi đột phá trong API dịch vụ của họ? Có thể hiểu được, sau đó chúng ta sẽ có lợi thế của API được nhập tĩnh mà mã UI xây dựng dựa trên. Nếu API thư viện máy khách thay đổi, thì mã UI sẽ không được biên dịch (vì vậy chúng tôi sẽ sớm biết rằng có một thay đổi đột phá). Tôi vẫn sẽ chạy các kiểm tra tích hợp khi xây dựng lớp UI hoặc lớp dịch vụ để xác nhận thêm rằng tích hợp giữa UI và (các) dịch vụ vẫn hoạt động.

Nói chung, đối với các phương thức API sắp hết, hãy chọn một quy ước và 'không dùng nữa', đặc biệt là ngay khi có đầy đủ, API thay thế có sẵn và được thử nghiệm. Giữ nguyên API cũ (về cơ bản), nhưng gắn thẻ siêu dữ liệu chữ ký phương thức hoặc chèn sự kiện ghi nhật ký để sử dụng có thể được xác định rõ ràng.

Đăng nhập vào API dịch vụ là một chuyện, nhưng cảnh báo khách hàng tiêu thụ lại là chuyện khác. Đối với REST, tôi không nghĩ có một thực hành tiêu chuẩn, vững chắc. Các máy khách API FourSapes có thể khám phá các phương thức không dùng nữa ngay cả khi phương thức được gọi là thành công (mã HTTP 200, tuy nhiên errorType sẽ được đặt thành 'không dùng nữa'). Có thể là một chiến lược hợp lý để cung cấp cho khách hàng tiêu dùng cơ hội hiểu biết về một phương pháp không dùng nữa trong API mà không gây ra sự chia rẽ.

https://developer.fiến.com/overview/responses

Trong hướng dẫn API của bạn, hãy đề xuất ngày hoặc số bản phát hành xây dựng nơi API không dùng nữa sẽ bị xóa hoàn toàn. Khi bạn xác định chiến lược của chúng tôi về sự phản đối, bạn sẽ muốn cảnh báo cho người tiêu dùng về API về chiến lược được đề xuất là gì (làm thế nào họ có thể phát hiện ra các phương pháp không dùng nữa, cách chuyển sang API thay thế và khi API không dùng nữa sẽ không còn nữa nếu thanh trừng trong quá trình dọn dẹp API) và thu hút phản hồi từ họ để đảm bảo quy trình này có lợi cho tất cả mọi người.

Phiên bản API của bạn là một khả năng khác. Khi một phiên bản mới được triển khai, hãy để phiên bản cũ hoạt động và cho phép đàm phán thông qua yêu cầu. Nếu bạn duy trì 2 hoặc 3 phiên bản gần đây nhất, thì mã UI có thể nâng cấp theo tốc độ của riêng nó.

Có ít nhất ba câu hỏi cùng một lúc, hãy thực hiện từng câu một

• "có một thư viện khách cho dịch vụ REST không?"

Rất có thể là có, miễn là bạn không muốn các cuộc gọi REST tùy ý phân tán trực tiếp qua tất cả mã UI của bạn.

• "có phải là một ý tưởng tốt để cho nhà phát triển của lớp dịch vụ tạo và duy trì lib không?"

Điều đó phụ thuộc vào những người trong nhóm của bạn. Người duy trì API nên biết cả hai thứ, những thứ có sẵn trong lớp dịch vụ cũng như các yêu cầu của lớp UI. Vì vậy, nó có thể là một người từ lớp dịch vụ hoặc một người từ lớp UI hoặc (tùy thuộc vào kích thước và các nhiệm vụ khác) một người độc lập với cả hai nhóm.

• [chúng ta sẽ có được lợi thế từ thực tế rằng] "nếu API thư viện máy khách thay đổi, thì mã UI sẽ không được biên dịch"

Không phải bạn nói UI sẽ được viết bằng Python sao? Đó không phải là ngôn ngữ được nhập tĩnh, vì vậy tôi sẽ không mong đợi sự phá vỡ bản dựng ngay lập tức từ thay đổi API. Tôi giả sử rằng tôi đã hiểu sai về bạn tại thời điểm này và bạn có API được nhập tĩnh tại đây - sau đó bạn có thể nhận được một số lợi thế ở đây miễn là bản dựng không bị hỏng khi chỉ thêm một số tính năng mới (như tham số tùy chọn mới) vào API. Nếu không, bạn sẽ tạo ra rất nhiều chi phí không cần thiết cho nhóm của bạn.