Giả sử bạn có một dịch vụ web, bổ sung logic nghiệp vụ trên đầu nguồn dữ liệu. Điều mà mỗi API của dịch vụ này trông khá giống - được đưa ra một tập các ràng buộc, đưa cho tôi các mục từ nguồn dữ liệu thỏa mãn các ràng buộc này. Bạn có thể nói rằng bạn nhận được "chế độ xem" nguồn dữ liệu từ API.
Bây giờ, theo thời gian bạn được yêu cầu trả lại các loại chế độ xem khác nhau đối với nguồn dữ liệu. Bạn có tùy chọn để thêm API mới cho mỗi chế độ xem "đủ khác biệt" hoặc để chuyển đổi bánh răng và cung cấp API getFooDataView (), lấy tham số chỉ định loại chế độ xem bạn muốn. Bạn có một số áp lực cạnh tranh để quyết định đi theo con đường nào:
- Khách hàng lớn hiện tại của dịch vụ của bạn muốn lười biếng hơn và không phải mã hóa các API mới khi cần có chế độ xem mới đối với dữ liệu.
- Tuy nhiên, một số tham số yêu cầu (ràng buộc) của bạn chỉ có ý nghĩa đối với một số chế độ xem chứ không phải cho các chế độ xem khác - bạn phải làm cho hợp đồng API của mình lỏng hơn bằng cách nói "tốt nếu bạn muốn xem XYZ, đặt tham số" foo "sẽ có không có tác dụng ", với tác dụng phụ đáng tiếc là bạn không thể biến" foo "thành một tham số bắt buộc ngay cả khi nó là như vậy đối với một số chế độ xem.
- Ngày càng có nhiều trường hợp khách hàng mới muốn tận dụng dịch vụ của bạn. Bạn không thể quyết định cái nào sẽ gây nhầm lẫn hơn cho họ - phải chọn giữa các API khác nhau nhưng được xác định chặt chẽ hơn và một API nơi họ phải biết kết hợp tham số nào thực sự mang lại cho họ những gì họ muốn.
Để chắt lọc điều này, khi nào bạn vẽ một dòng rằng một cái gì đó phải là API của chính nó chứ không phải là một biến thể của một API hiện có? Những người khác nhau mà bạn phải làm việc có quan điểm khác nhau về những gì làm cho hai yêu cầu của khách hàng khác biệt về mặt ngữ nghĩa, do đó khó có thể thúc đẩy sự đồng thuận về vấn đề này. Bạn cũng muốn đảm bảo rằng dịch vụ của bạn không gây khó khăn cho khách hàng trong tương lai. Một số thực hành tốt nhất khơi dậy sự lựa chọn này là gì?