relacja @OneToMany (Spring Boot, JPA)

Cześć,

Tworzę aplikację typu Reading Tracker, czyli któs ma w niej konta gdzie dodaje swoje książki i może aktualizować postęp etc.

Mam dwie klasy User i Book, chce stwrzoyć relacje taką, że User posiada Set<Book> natomiast w Book nie będzie odniesienia do tej relacji, bo nie ma takiej potrzeby. Chciałbym, żeby efektem końcowym były dwie tabelę i żeby w tabeli User mieć coś co przechowa zbiór tych książek, tylko pytanie jak to zrobić?

Czy np stworzyć listę Stringów odnoszących się do ID książek?

Jeżeli korzystasz NoSQL jak np. MongoDB to array stringów będzie OK, ale zakładam, że masz relacyjną bazę danych.
W takim wypadku będzie to relacja many to many, a nie one to many. Będziesz potrzebował tabeli łączącej, czyli takiej, która zawiera UserId i BookId, jako że użytkownik może czytaćdowolną ilość książek, a książka może zostać czytana przez wielu użytkowników. Dawno nie mialem do czynienia z relacyjnymi bazami danych, ale z tego co pamiętam jest zalecenie by unikać many-to-many i robić to za pomocą one to many, na zasadzie że robisz kolejną encję, która będzie reprezentować czytanie książki i tam masz relacje one to many i do książki i do użytkownika. Dzięki temu będziesz mógł przechowywać w tej encji/tabeli dodatkowe informacje jak np. czas rozpoczęcia czytania książki, ilość przeczytanych stron etc

Chyba że jedna książka może być przypisana tylko do jednego użytkownika - wtedy fakycznie robisz oneToMany, poszukaj tutoriali, ale w skrócie w encji User będziesz miał Set<Book> books, natomiast w encji Book, będziesz miał referencję User user. W sieci jest pełno poradników jak to upstrokacić adnotacjami i zakładam, że nie o to pytasz

Używam obecnie H2 czyli relacyjnej, w sumie mógłbym mieć na to osobną tabelę i specjalną encję na tą relacje, wydaje mi się dobry pomysł i dodatkowo tak jak napisałeś mógłbym trzymać dodatkowe informacje jak rozpoczęcie czytania itp.

A jak by to później wyglądało przy tworzeniu REST API? Najpierw bym musiał stworzyć np User'a z pustym zbiorem książek a później specjalne endpointy do wiązania książek z userem?

Dokładnie tak. Wyobraź sobie taki serwis, najpierw masz książki w bazie lub użytkownicy je dodadzą później. Masz też użytkowników, ale użytkownik najpierw niech się zarejestruje. Następnie użytkownik może dodać książkę, która czyta/przeczytał i może jakieś dodatkowe informacje, np. jeżeli czyta to na której jest stronie.
Endpointy pomijając GETy, to stwórz użytkownika, stwórz książkę, stwórz status - może to nie jest najlepsza nazwa, ale chodzi tu o status użytkownika względem danej książki, np w trakcie czytania. Do tego endpointy do aktualizacji użytkownika i statusu - użytkownik może zechcieć zmienić dane i z pewnością kiedyś skończy książkę czytać (lub np. przerwie czytanie).