2015-06-04 15 views
6

Vì vậy, tôi đã dành một vài giờ qua trolling thông qua tất cả lời khuyên thực sự tuyệt vời cho Web API Versioning. Một số yêu thích của tôi, đối với những việc có càng nhiều niềm vui như tôi, không theo thứ tự đặc biệt:Cấu trúc ngăn xếp API Web để Versioning

Best practices for API versioning?

Versioning REST API of an ASP.NET MVC application

http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html

http://www.pluralsight.com/courses/web-api-design

http://www.pluralsight.com/courses/implementing-restful-aspdotnet-web-api

Vì vậy, tất cả lời khuyên này rất hữu ích trong thiết kế về cơ bản là "giao diện người dùng" của API. Chúng tôi có thể phiên bản các cuộc gọi API ... Bây giờ, tôi đang ở phần khó khăn.

Đây là một ứng dụng hướng dữ liệu nặng nề, cho một công ty có nhiều sản phẩm (đây là một sản phẩm mới) đang phát hành hàng tháng. Một số khách hàng lớn, những người sẽ muốn hỗ trợ lâu dài cho các cuộc gọi API, một số khách hàng nhỏ hơn, những người sẽ muốn các bản phát hành mới nhất. Điều này chúng tôi có thể quản lý với một cái gì đó tương tự như mốc quan trọng/bản phát hành hỗ trợ dài hạn của API. Tuyệt quá.

Nhưng trong thực tế điều này sẽ thực sự lộn xộn, rất nhanh. Chúng tôi đã làm việc chăm chỉ để tách các lớp của trang web của riêng mình, các API nội bộ/bên ngoài beta, Lớp lưu trữ và thậm chí là một SDK để khởi động. Chúng tôi tách từng bản phát hành ra thành các nhánh riêng biệt, nhưng SAAS - chúng tôi lưu trữ cơ sở dữ liệu. Vì vậy, chúng tôi sẽ không thể phiên bản các cuộc gọi API - nhưng mọi thứ bên dưới đó. Logic nghiệp vụ, Kho lưu trữ và Cơ sở dữ liệu. Chúng ta thậm chí không bắt đầu vào bài kiểm tra Đơn vị/Tích hợp.

Vì vậy, cố gắng và có thể không chỉ hỏi một câu hỏi ở đây.

Có mô hình phù hợp để cấu trúc một ứng dụng .NET theo lớp, dựa trên dữ liệu để đối phó với nhiều phiên bản không?

Cụ thể cách cơ sở dữ liệu sẽ thay đổi và cách bạn có thể cấu trúc ngăn xếp chung để phiên bản tất cả. Một số ý tưởng tôi có bao gồm:

  • Cập nhật chi nhánh kiểm soát nguồn cũ của ngăn xếp và triển khai những
  • Giữ mọi thứ trong cùng một dự án, nhưng sử dụng thư mục/namespacing tất cả các con đường xuống
  • tách các dự án tiếp tục - do đó giải pháp API có một số dự án "Bộ điều khiển", với các khái niệm tương tự cho các lớp logic/repo

Chúng tôi có số lượng công bằng các nhà phát triển và cho dù tôi có viết bao nhiêu tài liệu, thực tế nó sẽ chỉ đọc khi một cái gì đó không hoạt động . Vì vậy, lý tưởng nó cần phải càng rõ ràng càng tốt cho các nhà phát triển để có được quyền này.

Trả lời

1

Không có giải pháp hoàn hảo phù hợp với mọi tình huống, cho dù có điều khiển dữ liệu hay không.

Điều này thực sự khó trả lời. Đặt cược tốt nhất của bạn là sử dụng nhiều chiến lược versioning.

Ví dụ: nếu thay đổi cơ sở dữ liệu chỉ đơn giản là thêm cột mới, các phiên bản cũ hơn của API có thể bỏ qua các cột mới.

Nếu thay đổi cơ sở dữ liệu có nghĩa là bạn phải viết lại hoàn toàn lớp kho lưu trữ, thì bạn có thể tạo kho lưu trữ mới và bộ điều khiển mới thay vì chỉ phiên bản một phương thức API. Sau đó, trên điểm cuối, bạn có thể phiên bản tuyến đường hoặc người tiêu dùng có thể gọi điểm cuối thay thế.

Nếu có những thay đổi đáng kể ở tất cả các cấp API, thì phiên bản tại IIS với thư mục ảo riêng có thể là giải pháp của bạn (và điều này có thể có các nhánh hoặc nhãn tương ứng trong điều khiển nguồn với mục đích hỗ trợ sửa lỗi/sửa lỗi).

Ý tưởng thư mục/không gian tên có thể gây nhầm lẫn cho các nhà phát triển, vì vậy tôi sẽ tránh xa nó. Định tuyến (tức là [Route ("/ v4/Orders")]) có thể là cách tốt hơn để xử lý nó. Một lần nữa, điều đó phụ thuộc vào bao nhiêu mã và bản chất của những thay đổi.

Các vấn đề liên quan