Nie wiem od czego zacząć. To wszystko zależy od twojej logiki aplikacji i obiektu który przesyłasz.
Masz Controller dedykowany dla Postów "PostController" np, więc generalnie odpowiada on za kontrolę zasobów URL dla postów, natomiast twój obiekt Post-> jest w relacji z Użytkownikiem który go napisał, okej więc twój obiekt "ma pole User"
Więc generalnie, nie ma mowy o przysyłaniu haseł, zresztą takowe są trzymane w hashu.
Ale żeby napisać post użytkownik np musi być autoryzowany, zarejestrowany. Więc jeśli pisze post, to mamy jego NICK, i np. ID
Te wartości będą w obiekcie Post dla pola User, nie potrzebujesz nic więcej i wtedy przy odbiorze obiektu Post, wybierasz dane dotyczących User i wykonujesz logikę
Spójrz na przykłądowe wykorzystanie obiektów z relacjami tutaj https://www.baeldung.com/spring-data-rest-relationships.
JSON w swoim ciele powinien zawierac pole, obiekt user, które ma określone atrybuty np id i nickname.
Druga sprawa, jeżeli napisałeś tak
public ResponseEntity addPost(@RequestHeader("username") String username, @RequestBody String postBody){
return postService.addPost(username, postBody);
}
to analizując to, prawdopodobnie "username" jest unikatowe? wtedy w Servisie jak chcesz dokonać jakiś operacji wydobywasz z bazy danych albo własnym QUERY pisząc, albo dostępnym w SRPING Data obiekt-encje dla User o wskazanym username i wykonujesz to czego Ci potrzeba.
@RequestHeader - adnotacja służy do przesyłania nagłówków, patrz dokumentacja. Więc tutaj nie ma mowy o przesyłaniu danych obiektu, to jest wręcz zabronione. Przysłane dane np w twoim wypadku username, to dane do walidacji a nie dotyczące obiektu przesyłanego.
@RequestBody - służy do przesyłania obiektu
W razie pytań wal śmiało
Na marginesie, masz dane gdyż sam napisałeś nullable, więc nie ma opcji, aby Post istnial bez usera, wiec i POLE OBIEKTU typu User posiada dane
@JoinColumn(nullable = false, ...)