serwis RESTful i edycja "po bożemu"

siemacie
pisze serwis restowy i zastanawiam się nad jedną rzeczą
jeśli rest po części polega na metodach tj. GET POST PUT DELETE OPTIONS itd. to znaczy ze przykladowo pod urlem:
/user/1 pod metoda GET bede czytal uzytkownika, pod DELETE przypuśćmy usuwał, pod PUT dodawal albo edytowal itd.

i teraz tak, nie wiem jak poręcznie wygląda to ze strony klienta, ale widze ze wszystko kręci sie wokół "id" encji. bo tak: w hibernate najwazniejsze jest id, a w podejsciu rest też wyczytałem, ze poprawne i przyjemne sa urle typu: /nazwa_encji/id_encji

i dlatego pytam: jesli chce edytowac przypuscmy user'a, chce to zrobic PUT'em, co z konwencji jest podmianą całości zawartości że tak powiem, to:

1. robie /user/ - metodą PUT i wysyłam w ciele JSON'owa nową postac usera, która ma id i sie podmienia w bazie
2. robie /user/{id} i w ciele znowu daje json usera? ale wtedy id mam jakby zdublowane, bo i w JSONie i w url'u

pytam bo mam problem z edycja, dostaje blad 400 jak 2x zedytuje te sama encje i jakoś mnie naszła myśl, że moze mam złe podejście

PUT /user/ wg. niektórych służy do podmiany wszystkich userów, ale to raczej mało praktyczne zastosowanie.
PUT /user/{id} powinno służyć do podmiany pojedynczego usera. Jeżeli problemem jest dla Ciebie id, to możesz zrobić kilka rzeczy... nie wymagać go w JSONie który przychodzi na ten URL, olać go zupełnie, porównać z tym z URLa i jeżeli są różne to zwrócić BAD REQUEST ze stosownym komunikatem. Wg. mnie najwygodniej było by nie wysyłać tego ID w ogóle, bo i tak użytkownik nie powinien móc zmienić swojego ID.

Zrob PUT /user/{id}, ktorego zachowania wyglada nastepujaco:

1. Jesli nie ma zasobu pod tym id i mozesz stworzyc nowy zasob na podstawie przekazanych danych, tworzysz go i zwracasz 201
2. Jesli jest zasob pod tym id, modyfikujesz go i zwracasz 200 lub 204
   I olej calkowicie przesylanie przez usera id jako dane.

@airborn @n0name_l dzieki za odpowiedzi.
czyli radzicie mi zaadnotować pole "id" jako @JsonIgnore?
jednak dalej troche mnie nie pokoi to "id" w centrum wydarzeń. patrzac ze strony klienta np. dla strony internetowej, na prawie kazdej stronie musze miec "id" usera zeby wykonywać jakieś-tam operacje na nim - cos mu dodac, cos zmienic itp. rozumiem, że aplikacja webowa nie bedzie sie opierała tylko na zabawie userem, ale czy @JsonIgnore na "id" nie ograniczy mi wtedy pola manewru?
bo np gdyby to byl portal spolecznosciowy to ja, chcąc znać id kolegi adama kowalskiego nie dostałbym go z JSON'a wtedy

ps.
sa jakies zasady co do tego, co powinna zwracać jakaś metoda? wiem, że np. GET 200 powinien zwrócić coś, bo w koncu getuje, za to DELETE nie powinno zwrocic usunietego zasobu, tylko nic i 204 NO CONTENT.

Jak to wyglada choćby dla 4 podstawowych metod: GET, POST, PUT, DELETE? która powinna cos zwrocic, która nie?
i czy to sie przekłada na warstwe repository/dao? w sensie: metoda do usuwania encji tez powinna byc void (nie zwrocic nic, ew. boolean)?

może byc tak, ze wszystko zalezy od tego co chcemy osiagnac, a nie ma jakichś odgórnych zasad, wiec wole zapytac niż żałować :)

czyli radzicie mi zaadnotować pole "id" jako @JsonIgnore?

Jak rozumiem ta adnotacja by wystepowala po stronie serwera i oznacza, ze do uzytkownika nie bedzie wysylane ID? W takim wypadku to bezsensu. Niech serwer wysyla to ID, ale pozniej niech uzytkownik nie przesyla go jako dane, tylko w sciezce do zasobu (bo po to ono jest).

sa jakies zasady co do tego, co powinna zwracać jakaś metoda?

W odpowiednim RFC jest opis kazdej jednej metody.

i czy to sie przekłada na warstwe repository/dao? w sensie: metoda do usuwania encji tez powinna byc void (nie zwrocic nic, ew. boolean)?

W zadnym wypadku. Do usuwania encji tez nie polecam stosowac void, usuniecie encji zawsze moze sie nie powiesc z jakichs powod. Juz lepiej jakies Maybe<Error>.

@n0name_l a jeśli nie prześle "id" w jsonie od klienta to Jackson ogarnie temat i utworzy obiekt bez id? (czyli z wartością 0 jak domniemam)
czyli tak jakby wysylajac obiekt od serwera normalnie słać całe entity razem z id, ale jak klient chce coś operować na obiekcie to id ma isc z url'a, a to które leci w ciele przesynalego jsona po prostu olać?

W modelu, ktory bedziesz tworzyc z tego jsona ma po prostu nie byc takiego pola jak id, po co one? Chyba nie chcesz mapowac bezposrednio tego co sle klient na encje bazodanowe?

Pytanie kto zarządza u Ciebie tym Id ? W większości przypadków to chyba serwer przydziela id nowo tworzonemu userowi. Jeżeli u Ciebie sprawa wygląda tak samo to przyjmujesz dane usera i jak się uda go zapisać to zwracasz 200 i w odpowiedzi id jaki mu przydzieliłeś. Zadaniem klienta jest przechwycić ten id i używać go do dalszych operacji jak np dodanie komentarza przez usera o otrzymanym Id.