Obsługa komunikatów zwracanych na front-end w WebAPI

1

Cześć,
w jaki sposób mogę obsługiwać po stronie backendu poprawnie komunikaty przekazywane na frontend, chodzi mi o komunikaty typu: user nie ma wystarczających uprawnień by coś zobaczyć, nieprawidłowo wysłane dane, czasem info że czegoś brakuje, coś nie jest poprawnie skonfigurowane, czegoś nie można zrobić bo nie zostały spełnione jakieś warunki.

Wcześniej myślałem żeby zrobić klasę typu ResponseObj, która by miała w sobie Object result (bądź generycznie o ile można), status, message i coś takiego zwracać za każdym razem, ale nie wydaje mi się że jest to dobre podejście. Więc może lepszym rozwiązaniem jest zwracanie normalnego obiektu jeśli jest ok (200,201), a jeśli coś nie tak, to jakiejś dedykowanej klasy ErrorResponse i zwracać coś na zasadzie return 403(ErrorResponse).
Tylko nie wiem czy dostępne statusy mi pokryją wszystkie ewentualności, czy martwię się na zapas, tez nie chce wykorzystywać wszystkich statusow bo by mnie pewnie frontend zjadł :P

Ale co zwrócić dla endpointa który ma np. przenieść jakiś towar z miejsca A na magazyn klienta, ale się okazuje, że klient nie ma przypisanego magazynu w systemie, 200 nie zwrócę bo operacja się nie powiodła, 400,401,403 to raczej też nie jest bo request poprawny, user zalogowany, uprawnienia do takiej operacji ma. Więc jak powiedzieć frontendowi że coś się nie udało?

0

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418

a tak serio to bym zwracał conflict ;)

1

Ja zazwyczaj robię tak że dla przypadków gdzie wystąpił błąd natury biznesowej, to zwracam 422 (Unprocessable Entity). Wtedy frontend wie że należy inaczej to obsłużyć i wyświetlić odpowiedni komunikat. Można również wprowadzić własne kody błędu (np. jakiś enum) i zwracać to w paylodzie, co pozwoli frontendowi na bardziej szczegółowe zmapowanie kodu na odpowiedni komunikat.

0

A jak success to 200, created 201, to dla updated, deleted jakie statusy będą odpowiednie?

1

A jak success to 200, created 201, to dla updated, deleted jakie statusy będą odpowiednie?

@blane: dla wszystkich HTTP Verbów zwracasz te same kody. Jeżeli PATCH/PUT/DLETE się udały to zwracasz 200 (OK), jeżeli nie znaleziono obiektu o id to 404. Jeżeli chcesz mieć ładne API to 201 zwracasz tylko dla stworzonych zasobów czyli w zasadzie dla każdego POST*.

Wszystko zależy w jaki poziom dojrzałości modelu Richardsona celujesz. Jeżeli to wewnętrzna apka to możesz wszędzie zwracać 200 (OK) jak się uda i 400 (Bad Request) jak się nie uda z error codem albo konkretną treścią błędu, którą sobie front ogarnie. Jeżeli chcesz piękne API dla klientów i np. chcesz zrobić zapytanie, które wyśle parametry nie w URLu jak GET tylko w body w POST to w pięknym świecie POST zwróci 201 (Created) z linkiem do odpowiedzi a odpowiedź właściwą pobierasz GETem.

Na start warto poczytać o modelu dojrzałości Richardsona i wybrać, który poziom jest dla nas odpowiedni, ewentualnie delikatnie zmodyfikować i tego poziomu się trzymać.
https://devkr.pl/2018/04/10/restful-api-richardson-maturity-model/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses

Co do opisanego przykładu z magazynem. Jest wiele opcji:

a) możesz na ładnie:
Robisz POSTa z requestem o zadanie. Zwraca 201. Front pobiera zasób (zwrócony z poprzedniej odpowiedzi) GETem i w ciele odpowiedzi jest czy operacja się udała. Request się udał, więc będzie to znowu 200, ale w ciele musi być info że np: "success": false, "error-message": Unable to magazyn
b) możesz na prosto:
Jak się udało to 200, jak się nie udało to 400 z error codem (jeżeli to był AJAX) a jeżeli musiałeś przeładować stronę to normalnie GET, 200 i w contencie informacja, żeby wyświetlić errora na froncie.

2
blane napisał(a):

Ale co zwrócić dla endpointa który ma np. przenieść jakiś towar z miejsca A na magazyn klienta, ale się okazuje, że klient nie ma przypisanego magazynu w systemie, 200 nie zwrócę bo operacja się nie powiodła, 400,401,403 to raczej też nie jest bo request poprawny, user zalogowany, uprawnienia do takiej operacji ma. Więc jak powiedzieć frontendowi że coś się nie udało?

422

blane napisał(a):

A jak success to 200, created 201, to dla updated, deleted jakie statusy będą odpowiednie?

200 lub 204 w zależności od tego, czy coś zwracasz, czy nie. Ja bym raczej nie zwracał.
Albo 202, jeśli proces jest długotrwały.

CosmoFire napisał(a):

@blane: dla wszystkich HTTP Verbów zwracasz te same kody. Jeżeli PATCH/PUT/DLETE się udały to zwracasz 200 (OK), jeżeli nie znaleziono obiektu o id to 404. Jeżeli chcesz mieć ładne API to 201 zwracasz tylko dla stworzonych zasobów czyli w zasadzie dla każdego POST*.

Ja bym jednak przemyślał to zwracanie 200 za każdym razem, bo to serio nie zawsze pasuje.

1 użytkowników online, w tym zalogowanych: 0, gości: 1