Mam do zrobienia prostą restową usługę. Zakładam sobie parametry wejściowe "id" i "akcja" na zasadzie akcji do wykonania. Mniej wiecej cos takiego: 1- zmien status 2- usun jezeli jakiś parametr na bazie = Y 3- usun jezeli jakiś parametr na bazie = X 4 - zwróć status
czyli np. moje zapytanie będzie wyglądać url?id=666&action=3
Teraz pytanie jak to obsłużyć zgodnie ze sztuką. Bo wykonywana akcji post/delete/get będzie zależeć od parametru "akcja" a nie od metody wysłanej w zapytaniu
@egzo2: raczej nie ma sensu: 1. po pierwsze primo, REST oznacza wykorzystanie metod HTTP (GET, POST itp) a nie jakiejś cyferki w zapytaniu. 2. po drugie primo, nawet jeżeli chcesz tak zrobić to czemu nie nazwiesz tych akcji po ludzku, np. action=getStatus zamiast action=4? 3. po trzecie primo, czemu akcje 2 i 3 nie mogą być obsługiwane bezpośrednio przez serwer? Skąd taki pomysł? Wygląda to dziwnie, jakby coś z logiką
@egzo2: Te parametry możesz otrzymywać w postaci URL, tak jak napisałeś, ale także możesz te parametry otrzymywać w postaci Json, wtedy dane mapujesz na odpowiedni obiekt i na podstawie tego decydujesz co dalej. Robiłem aplikacje w ten i w ten sposób, wszystko zależy jak biznes czy ktoś Ci te dane będzie przesyłał. Pamiętaj że warstwa kontrolerów powinna tylko odbierać request, tam nie ma być żadnej logiki.
Teraz pytanie jak to obsłużyć zgodnie ze sztuką. Bo wykonywana akcji post/delete/get będzie zależeć od parametru "akcja" a nie od metody wysłanej w zapytaniu
@egzo2: to osoba która Ci przesyła request, powinna zdecydować wymagania na tym poziomie, jeżeli żądania będą trzech typów post/delete/get, robisz trzy kontrolery, jeśli tylko jednego typu, robisz tylko 1 kontroler typu GetMapping i odbierasz parametry
@egzo2: możesz wszystko jechać POSTem, wtedy masz pseudo RPC. Po drugie dobrze radzą, wykorzystywanie magic numbers to nigdy nie jest dobry pomysł. Nazwany enum będzie lepszy.
@WujekMalysz11 @globalbus: A jeżeli chciałbym iść w takim kierunku w jakim jest to rozpisane u góry czyli akcja deklarowana jest po parametrze "action" to wtedy chyba najlepiej skorzystać z POSTA i w zależności od wartości parametru będe wykonał różną akcje?
@egzo2: z grubsza tak. Przy czym jak akcje są dwie lub trzy, to można dać nazwę akcji w path. Np /images/refresh/444 Nie znam reszty aplikacji, przyjętych konwencji, etc. Wszystkie rozwiązania są ok, jeśli są spójne w ramach jednego systemu.
Mam do zrobienia prostą restową usługę. Zakładam sobie parametry wejściowe "id" i "akcja" na zasadzie akcji do wykonania. Mniej wiecej cos takiego:
1- zmien status
2- usun jezeli jakiś parametr na bazie = Y
3- usun jezeli jakiś parametr na bazie = X
4 - zwróć status
czyli np. moje zapytanie będzie wyglądać url?id=666&action=3
Teraz pytanie jak to obsłużyć zgodnie ze sztuką. Bo wykonywana akcji post/delete/get będzie zależeć od parametru "akcja" a nie od metody wysłanej w zapytaniu
Czy takie coś ma wgl sens?
#programowanie #java
1. Put
2, 3. Delete
4. Get
1. po pierwsze primo, REST oznacza wykorzystanie metod HTTP (GET, POST itp) a nie jakiejś cyferki w zapytaniu.
2. po drugie primo, nawet jeżeli chcesz tak zrobić to czemu nie nazwiesz tych akcji po ludzku, np. action=getStatus zamiast action=4?
3. po trzecie primo, czemu akcje 2 i 3 nie mogą być obsługiwane bezpośrednio przez serwer? Skąd taki pomysł? Wygląda to dziwnie, jakby coś z logiką
Te parametry możesz otrzymywać w postaci URL, tak jak napisałeś, ale także możesz te parametry otrzymywać w postaci Json, wtedy dane mapujesz na odpowiedni obiekt i na podstawie tego decydujesz co dalej. Robiłem aplikacje w ten i w ten sposób, wszystko zależy jak biznes czy ktoś Ci te dane będzie przesyłał. Pamiętaj że warstwa kontrolerów powinna tylko odbierać request, tam nie ma być żadnej logiki.
To co zrobiłeś jak
@egzo2: to osoba która Ci przesyła request, powinna zdecydować wymagania na tym poziomie, jeżeli żądania będą trzech typów post/delete/get, robisz trzy kontrolery, jeśli tylko jednego typu, robisz tylko 1 kontroler typu GetMapping i odbierasz parametry
Po drugie dobrze radzą, wykorzystywanie magic numbers to nigdy nie jest dobry pomysł. Nazwany enum będzie lepszy.
Nie znam reszty aplikacji, przyjętych konwencji, etc. Wszystkie rozwiązania są ok, jeśli są spójne w ramach jednego systemu.