Prawo Demeter vs. REST

Question

Prawo Demeter (naprawdę powinno być sugestią Demeter) mówi, że nie powinieneś "docierać" do obiektu, aby dostać się do swoich obiektów podrzędnych. Jeśli ty, jako klient, musisz wykonać pewną nie banalną operację, w większości przypadków model domeny, z którym współpracujesz, powinien obsługiwać tę operację.

REST to w zasadzie głupia hierarchia obiektów. Jest jak system plików zasobów/obiektów, gdzie każdy obiekt może mieć obiekty podrzędne. Prawie zawsze uzyskujesz dostęp poprzez REST. Opcjonalnie można tworzyć typy obiektów złożonych według konwencji przy użyciu technik REST i dopóki dostawca i klient zgadzają się na operacje na wyższym poziomie, można uniknąć zasięgu.

Jak więc wyrównać REST i Demeter? Wydaje mi się, że nie są w konflikcie, ponieważ REST polega na super luźnym sprzężeniu do punktu, w którym usługodawca nie ma sensu przewidywać wszystkich potrzeb klientów, podczas gdy Demeter zakłada, że ​​logika może migrować do swoich klientów. najbardziej naturalne miejsce poprzez refaktoryzację.

Można jednak twierdzić, że REST to tylko przerwa, dopóki lepiej nie zrozumiesz swoich klientów. Czy REST to tylko hack? Czy Demeter jest nierealistyczny w jakimkolwiek scenariuszu serwer/klient?

Answer 1

• Czy Demeter jest nierealistyczny w każdym scenariuszu serwer/klient?

Myślę, że odpowiedziałeś na własne pytanie tutaj. Czym w tym przypadku jest REST inny niż SOAP lub XML-RPC?

Punkt REST nie jest dostarczenie bardzo luźne sprzężenie, ale następujący:

• zapewnić identyfikator które dokładnie opisano żądanego zasobu.
• świadczenia usług, które zachowują się zgodnie z oczekiwaniami GET wnioski są idempotent, PUT aktualizuje rekordy, POST tworzy, DELETE usuwa
• Minimalizacja stanu są przechowywane na serwerze
• Zburzyć niepotrzebnej złożoności

istnieją przypadki, gdy REST nie jest najlepszą odpowiedzią, ale REST działa wyjątkowo dobrze.

Answer 2

Płacę to prawo/sugestia bez względu na wszystko. Pokonuje połowę korzyści z agregacji i kompozycji, a ja go nie otrzymam.

Answer 3

Myślę, że są naprawdę ortogonalne. REST opisuje zbiór zasobów adresowanych przez URI z zestawem metod kanonicznych: GET, POST, itd. Jeśli procedura REST zwraca identyfikator URI, który nie "dociera", to identyfikuje inny obiekt o tych samych nazwach metod.

Answer 4

Łącze dostarczone przez reprezentację odsłoniętą przez interfejs RESTful może być całkowicie nieprzezroczyste bez naruszania jakichkolwiek ograniczeń REST. Dlatego sugerowałbym, że REST jest całkowicie zgodny z Prawem Demeter. Nie ma wymogu, aby link ujawniał strukturę przestrzeni adresów URL w adresie URL.

np. w scenariuszu obiektowym można zastąpić wywołanie a.b.c przez.bc

w spokojnej reprezentacji można tworzyć następujące:

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

zamiast robić

GET a 

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

GET b 

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

GET c 

musiałbym zgodzić się z altCognito i powiedzieć, że jednym z głównych celów reszta jest luźne powiązanie. Uniwersalny interfejs, standardowe typy nośników i HATEOAS wszystko to razem tworzą niezwykle luźny interfejs.

W odpowiedzi na komentarz Dawida:

reszta jest wszystko o super-luźne sprzęgła do punktu, w którym nie ma sensu dla dostawcy, aby spróbować przewidzieć wszystkich potrzeb klientów

W rzeczywistości REST polega na ograniczaniu opcji klientów poprzez podawanie tylko poprawnych odnośników w reprezentacjach. W ramach tych ograniczeń klient może próbować zaspokoić własne potrzeby. Jest to przez usunięcie wiedzy od klienta o tym, kiedy można wnioskować o pewnych wnioskach, aby uzyskać luźne połączenie. Luźne sprzężenie nie jest osiągane przez wymienienie zestawu zasobów i powiedzenie "OK, możesz GET, PUT, POST, DELETE wszystko, co chcesz."