Liệu decoupling Trump DRY trong REST?

Tôi đang xây dựng API REST để hiển thị hầu hết chức năng của API Java hiện có. Cả hai API đều được sử dụng nội bộ trong tổ chức của tôi; Tôi không phải thiết kế để sử dụng bên ngoài. Tôi có ảnh hưởng đến cả hai API nhưng đang triển khai REST. API Java sẽ tiếp tục được sử dụng cho các ứng dụng cục bộ (nó không bị "nghỉ hưu"), nhưng API REST sẽ được sử dụng để phát triển mới đáng kể.

Một số lớp API Java chỉ đơn giản là dữ liệu (các bean có thuộc tính, getters, setters). Và ít nhất một số trong số này có ý nghĩa để truyền (dưới một hình thức nào đó) qua API REST dưới dạng dữ liệu (sẽ được sắp xếp theo XML hoặc JSON). Ví dụ, một lớp lưu trữ thông tin về một máy chủ. Tôi phải đối mặt với sự lựa chọn sau đây cho các lớp dữ liệu này: Tôi có ...

1. hiển thị trực tiếp lớp Java gốc (hoặc một lớp con) trong API REST hoặc
2. tạo một lớp truyền dữ liệu mới (mẫu DTO) cụ thể cho API REST?

Dù bằng cách nào tôi cũng sẽ có các lớp chuyển dữ liệu REST; câu hỏi là có nên chú thích bản gốc hoặc tạo bản mới (có thể gần bản sao của bản gốc). Có thể có những lựa chọn khác, nhưng tôi sẽ tập trung chủ yếu vào hai thứ đó.

Đối số cho # 1:

• DRY (không lặp lại chính mình)
• Nhanh hơn để thực hiện
• Dễ dàng nâng cấp API REST

Đối số cho # 2:

• Điều gì xảy ra nếu API REST cần được phiên bản riêng với API Java? (Điều này có khả năng.)
• Điều gì xảy ra nếu có các thay đổi đáng kể đối với các lớp dữ liệu Java như loại bỏ các thuộc tính, thêm hành vi hoặc thay đổi vào hệ thống phân cấp lớp? (Điều này cũng có khả năng.)

Điểm mấu chốt là có vẻ như là một sự đánh đổi giữa DRY (# 1) và tách rời (# 2).

Tôi đang nghiêng về việc bắt đầu với số 1 và sau đó nếu có vấn đề phát sinh chuyển sang số 2 sau đó, tuân theo nguyên tắc nhanh nhẹn là không xây dựng những gì bạn không thể chứng minh bạn cần. Đây có phải là một ý tưởng tồi; Tôi có nên bắt đầu với # 2 nếu tôi nghĩ tôi có thể kết thúc ở đó không?

Có những tranh luận / hậu quả chính bị thiếu trong danh sách của tôi không?

Câu hỏi hay, chỉ đơn giản là đặt, tách rời. Đó là cách để đi đến đây, bạn không muốn bị ràng buộc với phiên bản java.

Có một kịch bản mà bạn không tách rời: nếu công nghệ của bạn sẽ cho phép các đối tượng không phải là loại cụ thể được gửi qua dây, đó là, nếu bạn có thể sử dụng các đối tượng java hiện tại làm YAGNI và thay thế bằng một đối tượng khác loại mà bạn tùy chỉnh sẽ là một kiểu thả đơn giản sẽ không phá vỡ bất cứ thứ gì do thông tin loại đi qua dây. Vì vậy, về cơ bản nếu thông tin loại không vượt qua dây, bạn có thể YAGNI về điều này.

Chỉ cần cẩn thận và thận trọng rằng mọi nâng cấp cho phiên bản java của bạn sẽ không thay đổi bất kỳ đối tượng nào trong số này. Nếu không, bây giờ chỉ cần tách rời và đừng lo lắng về điều đó, tôi đoán nó phụ thuộc vào thời gian bạn có nếu bạn có một sự lựa chọn.

Tuy nhiên, nếu thông tin loại đi qua dây trong giao thức của bạn thì việc loại bỏ các kiểu mới khi các kiểu java cơ bản thay đổi có thể không thực hiện được và có thể là một nỗ lực lớn hơn. Nếu đó là trường hợp, đi YAGNI bây giờ có nghĩa là tích lũy nợ kỹ thuật và rủi ro liên quan đến công nghệ cơ bản của bạn.

Cá nhân tôi sẽ chỉ tách rời bây giờ.

Ngoài ra, DRY không tham gia vào điều này bởi vì bạn đã không viết các phần cơ bản để bạn không sao chép mã và do đó sẽ không có lỗi lặp đi lặp lại, đó là mối quan tâm chính của DRY (và khả năng bảo trì chung những vấn đề mà bạn sẽ không gặp phải vì bạn không có bản sao để duy trì)

Các đối số chính cho # 1 là dễ thực hiện và nâng cấp, nhưng nó có đáp ứng yêu cầu của bạn không?

Trong các đối số của bạn cho # 2, bạn chỉ ra rằng API Java và API REST có thể có thể thay đổi độc lập. Điều này có nghĩa là chúng là những mối quan tâm riêng biệt và bạn không lặp lại chính mình bằng cách sử dụng các lớp riêng biệt. Chỉ vì hai điều giống nhau, không có nghĩa họ là giống nhau.

API REST của bạn không phải tuân theo cấu trúc giống như mô hình dữ liệu của bạn

Khi triển khai REST, hãy đảm bảo rằng bạn đang tạo API bên ngoài trực quan và sau đó ánh xạ nó tới các lớp mô hình dữ liệu nội bộ của bạn. Điều này cho phép bạn thay đổi từng độc lập với các API khác có thể tồn tại hàng thập kỷ .

Do đó, tách rời là cách để đi đến đây.