Czy odsprzężenie ma atut DRY w REST?

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?

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)

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 są takie same.

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ą.