Czy odsprzężenie ma atut DRY w REST?

19

Buduję interfejs API REST, aby udostępnić większość funkcjonalności istniejącego interfejsu API Java. Oba interfejsy API są do użytku wewnętrznego w mojej organizacji; Nie muszę projektować do użytku zewnętrznego. Mam wpływ na oba interfejsy API, ale wdrażam interfejs REST. Interfejs API Java będzie nadal używany w aplikacjach lokalnych (nie jest „wycofywany”), ale interfejs API REST będzie wykorzystywany do nowych znaczących prac rozwojowych.

Niektóre klasy API Java to po prostu dane (komponenty bean z właściwościami, pobierające, ustawiające). I przynajmniej niektóre z nich mają sens transmitować (w jakiejś formie) przez interfejs API REST jako dane (które zostaną przekazane do XML lub JSON). Na przykład klasa przechowująca informacje o maszynie serwerowej. Mam do czynienia z następującym wyborem dla tych klas danych: Czy ...

  1. udostępnić oryginalną klasę Java (lub podklasę) bezpośrednio w interfejsie API REST, lub
  2. utworzyć nową klasę przesyłania danych (wzorzec DTO) specjalnie dla interfejsu API REST?

Tak czy inaczej będę mieć klasy przesyłania danych REST; pytanie brzmi, czy adnotować oryginały, czy utworzyć nowe (które mogą znajdować się w pobliżu kopii oryginałów). Mogą być inne opcje, ale skupię się głównie na tych dwóch.

Argumenty za nr 1:

  • SUCHO (nie powtarzaj się)
  • Szybszy do wdrożenia
  • Łatwiejsza aktualizacja REST API

Argumenty za # 2:

  • Co jeśli REST API musi być wersjonowany oddzielnie od Java API? (Jest to dość prawdopodobne.)
  • Co się stanie, jeśli nastąpią znaczące zmiany w klasach danych Java, takie jak usunięcie właściwości, dodanie zachowania lub zmiany w hierarchii klas? (Jest to również nieco prawdopodobne).

Najważniejsze jest to, że wydaje się to kompromisem między OSUSZANIEM (nr 1) i oddzieleniem (nr 2).

Skłaniam się do rozpoczęcia od nr 1, a następnie, jeśli pojawią się problemy, przejście do nr 2 później, zgodnie ze zwinną wytyczną, aby nie budować tego, czego nie możesz udowodnić, że potrzebujesz. Czy to zły pomysł; powinienem zacząć od nr 2, jeśli myślę, że i tak mogę tam skończyć?

Czy na moich listach brakuje istotnych argumentów / konsekwencji?

Wola
źródło
Jeśli pamiętam PragProg, naprawdę SUCHĄ rzeczą byłoby posiadanie jednego źródła, z którego ZARÓWNO klasa Java ORAZ dto są generowane .
AakashM
„Co jeśli” = YAGNI IMO
Jonathan Obsada

Odpowiedzi:

10

Dobre pytanie, po prostu, oddzielić. To jest sposób, aby przejść tutaj, nie chcesz być przywiązany do wersji Java.

Jest jeden scenariusz, którego nie rozdzielisz: jeśli twoja technologia pozwoli na przesyłanie przez sieć obiektów niespecyficznych dla typu, to znaczy, że możesz teraz używać obecnych obiektów Java jako YAGNI, i zastąpić je innym niestandardowy typ będzie prostym drop-in, który niczego nie zepsuje, ponieważ informacje o typie przechodzą przez drut. Zasadniczo, jeśli informacja o typie nie przechodzi przez przewód, możesz na tym YAGNI.

Po prostu bądź bardzo uważny i uważny, aby jakiekolwiek aktualizacje do wersji Java nie zmieniały żadnego z tych obiektów. W przeciwnym razie po prostu odsprzęgnij teraz i nie przejmuj się, myślę, że to zależy od tego, ile masz czasu, jeśli masz wybór.

Jednakże, jeśli informacje o typie przechodzą przez protokół w protokole, wówczas płaski spadek nowych typów, gdy zmieniają się typy typów Java, może nie być możliwy i może być raczej większym wysiłkiem. W takim przypadku przejście na YAGNI oznacza teraz narastanie długu technicznego i ryzyka związanego z technologią bazową.

Osobiście po prostu rozdzieliłbym teraz.

Ponadto DRY nie bierze w tym udziału, ponieważ nie napisałeś podstawowych elementów, więc nie powielasz kodu, a zatem nie będziesz mieć problemów z powtarzającymi się błędami, co jest głównym problemem DRY (i ogólna łatwość konserwacji problemy, których znowu nie będziesz mieć, ponieważ nie masz duplikatów do utrzymania)

Jimmy Hoffa
źródło
7

Główne argumenty przemawiające za numerem 1 to łatwość implementacji i aktualizacji, ale czy spełnia twoje wymagania?

W swoich argumentach za nr 2 wskazujesz, że Java API i REST API mogą się zmieniać niezależnie. Oznacza to, że są to osobne obawy i nie powtarzasz się, używając oddzielnych klas. To, że dwie rzeczy wyglądają tak samo, nie oznacza, że takie same.

Misko
źródło
6

Interfejs API REST nie musi mieć tej samej struktury co model danych

Podczas wdrażania REST upewnij się, że tworzysz intuicyjny zewnętrzny interfejs API, a następnie zamapuj go na wewnętrzne klasy modeli danych. Umożliwia to zmianę każdego niezależnie od siebie, co prowadzi do interfejsów API, które mogą trwać dekady .

Dlatego oddzielenie płatności jest tutaj właściwą drogą.

Gary Rowe
źródło