Jak wczytać szczegółowe dane zasobu do GUI?

Hej, od jakiegoś czasu piszę hobbystycznie aplikację typu CRUD - stos standardowy Java + Spring a na froncie Angular.

Ostatnio napotkałem na zagwozdkę, która nie daje mi spokoju. Podczas tworzenia nowej funkcjonalności związanej z moją aplikacją natrafiłem na konieczność pobrania danych szczegółowych dotyczących zamówienia którego stronę odwiedzam w celu podglądu i/lub edycji. Zastanawiam się w jaki sposób zabrać się za odpytanie o konkretne zamówienie, aby było to zrobione poprawnie. Czy pobierać dane o zamówieniu w jednym zapytaniu, a później dodatkowe dane z nim zwązane w drugim? Cos na kształt request pod orders/{id} a później osobne zapytanie pod orders/{id}/items?

Żeby zobrazować to dokładniej:

• z punktu GUI wchodzę na stronę z zamówieniami i wybieram z listy konkretną pozycję -> klikam w celu przejścia do widoku edycji. Wyświetlają się dwie kolumny - jedna z ogólnymi informacjami dotyczącymi zamówienia (dokładnie to samo co w tabeli ORDERS w mojej bazie danych) a w drugiej dane dotyczące wszystkich pozycji zamówienia przypisanych do tego zamówienia (dokładnie to co w tabeli ORDER_POSITIONS w mojęj bazie danych) - lista pozycji, które każde powinno być możliwe do edytowania i zapisania zmian.
• 
• z punku BAZY DANYCH Mam dwie tabele ORDERS i ORDER_POSITIONS - tabela ORDERS przechowuje podstawowe dane dotyczące zamówień, natomiast tabela ORDER_POSITIONS zawiera referencję na zamówienie oraz dodatkowe informacje dot. każdej z pozycji zamówienia itd. Innymi słowy tabela ORDER_POSITIONS może zawierać kilka rekordów które wskazują na konkretny rekord z tabeli ORDERS
  

Jaki efekt chce osiągnąć?
Z warstwy GUI po wejściu w tryb edycji:

1. Chciałbym wyświetlić zarówno to co zawarte jest w tabeli ORDERS i ORDER_POSITIONS. tak, aby umożliwić edycję wszystkich wyświetlonych danych. Pytanie czy powinieniem całość danych zaciągać w formie jednego zapytania, czy osobno dla zamówienia i osobno dla listy powiązanych pozycji?
   
2. Co zrobić z danymi z tabeli ORDER_POSITIONS w momencie próby zapisu? Jak powinienem rozwiązać te kwestie? Czy w momencie próby zapisania wysyłać JSONA z danymi zarówno samego zamówienia jak i wszystkich pozycji zamówienia? Czy te dwie operacje powinny zostać rozdzielone?

Mam wrażenie, że nie ma jednoznacznej odpowiedzi/ standardu dotyczącego takiej funkcjonalności, jednocześnie nie potrafię sam zdecydować się na któreś z opisanych przeze mnie rozwiązań. Macie jakieś pomysły albo sugestie?

Wydaje mi się, że żle do tego podchodzisz, uzależniasz projektowanie swojego systemu od bazy danych zamiast od reguł biznesowych. Proponował bym najpierw zacząć od "rozkimny" jak ma to wyglądać na GUI potem napisz do tego backend, a na samym końcu spróbuj do tego wszystkiego dostosować bazę wraz z relacjami (albo bez, bo często i gęsto wychodzi na końcu, że relacyjna baza danych jest niepotrzebna).

Brakuje ci wyobrażenia o tym jak chcesz żeby twoja aplikacja działała, innymi słowy nie masz konkretnych wymagań. Robisz coś nie myśląc jak to ma działać od strony biznesowej stąd twoje rozterki.

Czemu chcesz żeby GUI zależało od twojego schematu bazy danych? Poczytaj o architekturze Clean/Onion, DTO/View Modelach. W skrócie działa to tak, że z frontendu leci request do API, API wywołuje serwis/handler, który wykonuje zapytanie db o dane i dane są mapowane na DTO/View Model.

Co do sposobu ładowania danych na GUI to możesz to zrobić tak i tak. Nie ma jednej słusznej drogi. Sposób w jaki pobierasz dane i ładujesz na UI zależą od wymagań funkcjonalnych i niefunkcjonalnych. W aplikacjach które operują na dużych zbiorach danych trzeba bawić się w optymalizacje, lazy loading, doładowywanie danych w trakcie scrollowania itd.W aplikacjach które nie mają tego typy problemów można zrobić najprościej jak się da, nie bawiąc się w czary mary.

Co do aktualizacji pozycji zamówienia to znowu zależy od tego jak masz zamodelowany model dziedzinowy. Jeśli masz reguły biznesowe i niezmienniki które muszą być zachowane w trakcie aktualizacji zamówienia to bezpiecznie jest to zrobić przez aktualizację obiektu Order wysyłając jednego JSONa. Jeśli nie masz logiki i pozwalasz tylko na aktualizacje pozycji zamówienia to możesz zaktualizować tylko te pozycje zamówienia, które należą do edytowanego zamówienia,

W skrócie za mało konkretnych informacji, żeby udzielić konkretnej rady.

Rozbicie na 2 requesty powoduje komplikacje, choćby takie - jeśli request 1 się powiedzie a drugi nie to co wtedy pokazać użytkownikowi?