Cześć, tak jak na obrazku powyżej - niby wszystko jasne, ale u mnie moje wiadomości mają unikalne id. Dlatego mógłbym zrobić po prostu coś w stylu
PUT /messages/5
Ale czy to poprawne? Czy dla picu powinienem używać
PUT /tickets/12/messages/5
Czy może ja to w ogóle jakoś źle robie? Może dla każdego ticketu wiadomości powinny się zaczynać od 1? W takim razie jak by taka struktura w bazie miała wyglądać?
Skoro dorzucenie /tickets/:id do URLa jedynie utrudnia routing oraz obsługiwanie wiadomości, to w jakim celu miałbyś to robić?
Pragmatyzm oraz prostota ponad puryzm.
W takim razie jak by taka struktura w bazie miała wyglądać?
Mógłbyś utworzyć dodatkowe pole o nazwie incremental_id z unikalnym kluczem na (ticket_id, incremental_id) (tak robi np. Magento dla idków zamówień) - przy czym imho nie ma to sensu, ponieważ jedynie zaciemi to wczytywanie oraz tworzenie nowych wiadomości (insert into będziesz musiał poprzedzić select max(...) + 1 ...).
Takie podejście do rozpoznawania parametrów to przy bardzo prostych serwisach i bardzo prostych zapytaniach.
I tu kolejny problem: proste serwisy mogą się w pewnym momencie rozbudować do dużych (mniejsza w tym momencie o kryteria podziału).
W każdym razie przy większych serwisach gdzie masz więcej operacji niż CRUD, tego typu konstrukcje to jakaś masakra, tak samo jak przekazywanie parametrów w ten sposób:
/moje/przeboje,param,param,param,param (np. /moje/przeboje,12,34,fr,23534)
Dlaczego u niektórych istnieje taka awersja przed tradycyjnymi parametrami przekazywanymi w tradycyjny sposób (?param=val¶m=val), które co więcej są rozpoznawane przy POST nie tylko przy GET, i uelastyczniają cały system.
Z tego co pokazujesz na poczatku, to projektujesz swoje api na kształt REST-owego. Jeśli tak jest, to warto trzymać się powszechnie przyjetych konwencji (chyba że to mały serwis ale - one szybko rosną). To ułatwia pracę np. tym którzy przejmą twoj kod, albo będa z nim pracować, ogladać go, używać.
Tu jest jeden z wielu przewodników po budowie RESTapi - https://restfulapi.net/rest-api-design-tutorial-with-example/#model-uris. Poczytaj, nawet jeśli twoj bedzie tylko REST, a nie RESTfull.
A poza tym tak skonstruowany uri tickets/12/messages/5 od razu zwiera w sobie sporo informacji, które w przeciwnym wypadku musiałbyś wyciągać z bazy. Oczywiście i tak trzeba je walidować, ale na dzień dobry dostajesz jaśniejszą strukturę.
No i polecem nie uzywac intów jako indentyfikatorów, tylko przejśc na UUID-y.