Mam encję Task (zadanie) z polami takimi jak m.in taskDescription (opis zadania), które jest jej identyfikatorem, ponieważ każdy opis ma być unikalny i nie widziałem tu sensu dawania jakiegoś idka w postaci liczby. Tylko teraz z rest api jest taki problem, że jak mam metodę do pobierania taska po tym descriptionie z argumentem oznaczonym @PathVariable, to tworzy się taki url np.: localhost:8080/api/tasks/Wash dishes. ,który co prawda działa, ale raczej nie powinien tak wyglądać. Da się jakoś to przerobić, żeby tworzył się url w postaci localhost:8080/api/tasks/washdishes czy coś w tym stylu?
0
2
Super podejście, czyli jak opis będzie miał 200 słów, to będziesz to pchał do urla? ;) daj klientom jakiś bardziej cywilizowany ID, na poziomie modelu tez Ci się taki przyda jak będziesz modelował relacje między encjami. Przecież nie będziesz jako referencje trzymał całego opisu. Nie mówiąc już o tym, ze za chwile ktoś będzie chciał zmienić opis :) to podejście jest całkowicie „z czapy”.
0
@Charles_Ray: Domyślam się słabości takiego rozwiązania, ale jakie są sensowne alternatywy? Niby mogę dać możliwość pobierania tasków po idku, tylko klient podając 1 myśli, że dostanie pierwszy element z listy a może nie dostać nic mimo tego, że w bazie może być kilka tasków tylko mimo autoincrement id tasku o tym id nie ma tylko są np. 4,7,10, bo ktoś wcześniej usunął taska o idku 1 itd. Chyba, że da się to jakoś ustawić, żeby idki w bazie po usunięciu taska ustawiały się na nowo od 1.
2
jakie są sensowne alternatywy?
Autoincremental id / UUID.
Niby mogę dać możliwość pobierania tasków po idku, tylko klient podając 1 myśli, że dostanie pierwszy element z listy
Klient spojrzy do dokumentacji, przeczyta opis endpointu i nie będzie miał żadnych wątpliwości.
Chyba, że da się to jakoś ustawić, żeby idki w bazie po usunięciu taska ustawiały się na nowo od 1.
No ale... po co - co jest złego w niekonsekutywnych idkach w stylu 4, 7, 10? Użytkownik końcowy i tak ich nie będzie widział.
1
Jw. sekwencja z bazy, względnie własny UUID
1
Taki bazodanowy id w ogóle nie powinien być zwracany do użytkownika na front(zamiast tego bezpiecznie możesz zwracać wspomniany uuid).
Jeżeli używasz Hibernate'a (a pewnie używasz) to i tak powinieneś zastosować UUID do identyfikowania encji w kontekście chociażby tego, że Hibernate taką encją zarządza.
Co więcej, w czasie tworzenia obiektu (przed zapisem) nie masz jeszcze id(nadawanego w czasie zapisu do bazy przez silnik bazodanowy) więc takie UUID się przydaje (warto na nim oprzeć metodę equals/hashcode).
Inna sprawa, że String jako id jest słaby z punktu widzenia wydajności.
Zobacz sobie to wystąpienie Kuby Kubryńskiego:
0
Pchanie encji bazodanowej JPA na REST zaraz za zakrętem cię kopnie w d., np problemy z serializacją JSON
0
@AnyKtokolwiek: Gdzie ja napisałem, że pcham encję JPA na Resta? Na Resta zwracam dto.
2
Jak ci nie zależy na czytelności URLi bo nie spodziewasz się że będą gdzieś wyświetlane to nie baw się tylko używaj sekwencji albo UUID. UUID mogą być problemem w SQLowych bazach, ale te problemy się pojawiają raczej w dużych systemach. Sekwencje mogą być używane do enumerowania zasobów co może ale nie musi być problemem. Teraz często widuje się sekwencje używane jako PK i UUID wystawiane przez backend.
Z takich ciekawostek - Nofluffjobs rozwiązali problem czytelności urli i wiązania z bazą w ciekawy sposób - url do oferty ma część tekstową i zaraz za nią IDka, część tekstowa zmienia się wraz ze zmianami wprowadzanymi przez klientów, ale ID zostaje taki sam, na przykład poniższe linki to ta sama oferta:
https://nofluffjobs.com/pl/job/cobol-engineer-avenga-warszawa-vrtbcyxk
https://nofluffjobs.com/pl/job/jakis-biedny-staruszek-do-utrzymania-shitu-ktory-powinien-dawno-umrzec-vrtbcyxk