Luật Demeter so với REST

Question

Luật Demeter (thực sự nên là đề xuất của Demeter) nói rằng bạn không nên "tiếp cận" một đối tượng để có được đối tượng con của họ. Nếu bạn, với tư cách là một khách hàng, cần thực hiện một số hoạt động không tầm thường, phần lớn thời gian mà mô hình miền bạn đang làm việc phải hỗ trợ hoạt động đó.

REST về nguyên tắc là một hệ thống phân cấp câm của các đối tượng. Nó giống như một hệ thống tập tin của các tài nguyên/đối tượng, trong đó mỗi đối tượng có thể có các đối tượng con. Bạn hầu như luôn luôn đạt được thông qua với REST. Bạn có thể tùy ý xây dựng các loại đối tượng hỗn hợp theo quy ước bằng cách sử dụng các kỹ thuật REST và miễn là nhà cung cấp và khách hàng đồng ý với các hoạt động cấp cao hơn, bạn có thể tránh được việc tiếp cận.

Vì vậy, bạn cân bằng giữa REST và Demeter như thế nào? Dường như với tôi rằng họ không xung đột, bởi vì REST là tất cả về sự liên kết siêu lỏng đến mức mà nó là vô nghĩa cho nhà cung cấp để cố gắng dự đoán mọi nhu cầu của khách hàng, trong khi Demeter giả định rằng logic có thể di chuyển đến nơi tự nhiên nhất thông qua tái cấu trúc.

Tuy nhiên, bạn có thể lập luận rằng REST chỉ là khoảng cách dừng cho đến khi bạn hiểu khách hàng của mình tốt hơn. Là REST chỉ là một hack? Demeter không thực tế trong bất kỳ kịch bản máy chủ/khách hàng nào?

Answer 1

• Demeter không thực tế trong bất kỳ trường hợp máy chủ/khách hàng nào?

Tôi nghĩ bạn đã trả lời câu hỏi của riêng bạn tại đây. Làm thế nào là REST theo cách này khác với SOAP hoặc XML-RPC trong lĩnh vực này?

Mấu chốt của REST không phải là để cung cấp khớp nối siêu lỏng lẻo, nhưng những điều sau:

• Cung cấp một định danh trong đó mô tả một cách chính xác các tài nguyên được yêu cầu.
• Cung cấp dịch vụ mà cư xử như mong đợi GET yêu cầu là idempotent, PUT cập nhật hồ sơ, POST tạo, DELETE xóa
• Giảm thiểu tình trạng được lưu trữ trên máy chủ
• Tear xuống phức tạp không cần thiết

Có những trường hợp REST không phải là câu trả lời hay nhất, nhưng REST hoạt động khá tốt nói chung.

Answer 2

Tôi trả tiền rằng luật/đề xuất không có bất cứ điều gì. Nó đánh bại một nửa lợi ích của việc tập hợp và sáng tác, và tôi sẽ không có nó.

Answer 3

Tôi nghĩ rằng chúng thực sự trực giao. REST mô tả một tập hợp các tài nguyên được giải quyết bởi các URI với một tập hợp các phương thức kinh điển: GET, POST, vv Nếu thường trình REST trả về một URI, đó không phải là "tiếp cận" nó xác định một đối tượng khác với cùng tên phương thức.

Answer 4

Một liên kết được cung cấp bởi một biểu diễn, được hiển thị bởi giao diện RESTful, có thể hoàn toàn mờ đục mà không vi phạm bất kỳ ràng buộc nào của REST. Do đó tôi đề nghị rằng REST hoàn toàn phù hợp với Luật Demeter. Không có yêu cầu liên kết hiển thị cấu trúc của không gian URL trong URL của nó.

ví dụ: trong một kịch bản hướng đối tượng, bạn có thể thay thế cuộc gọi a.b.c bằng a.bc

Trong một đại diện RESTful bạn có thể tạo ra những điều sau đây:

<a> 
    <link href="bc"/> 
</a> 

thay vì làm

GET a 

    <a> 
     <link href="b"/> 
    </a> 

GET b 

    <b> 
     <link href="c"/> 
    </b> 

GET c 

tôi sẽ phải đồng ý với altCognito và nói rằng một trong những mục tiêu chính của REST là khớp nối lỏng lẻo. Giao diện đồng bộ, các loại phương tiện tiêu chuẩn và HATEOAS kết hợp để tạo ra một giao diện cực kỳ lỏng lẻo.

Đáp lại bình luận của David:

Văn là tất cả về khớp nối siêu lỏng lẻo đến điểm mà nó là vô nghĩa đối với các nhà cung cấp để cố gắng dự đoán tất cả các nhu cầu của khách hàng

Trên thực tế, REST là giới hạn các tùy chọn của khách hàng bằng cách chỉ cung cấp các liên kết hợp lệ trong các biểu diễn. Trong những hạn chế đó, khách hàng có thể cố gắng thỏa mãn các nhu cầu riêng của mình. Đó là bằng cách loại bỏ các kiến ​​thức từ khách hàng khi yêu cầu nhất định có thể được thực hiện mà bạn đạt được khớp nối lỏng lẻo. Khớp nối lỏng lẻo không đạt được bằng cách liệt kê một tập hợp các nguồn lực và nói "ok, bạn có thể GET, PUT, POST, DELETE tất cả các bạn muốn."