Witam.
Proszę o podpowiedz jakie kody błędów powinienem zwracać do Frontu, przykładowo gdy podany do usunięcia w BD rekord o danym ID nie istnieje, albo nie można stworzyć nowego bo nazwa już istnieje itp.
0
0
422 bo powinno to być wykryte przez validację. http://www.restpatterns.org/HTTP_Status_Codes
0
W jaki sposób mogę to validować ? Bo przychodzi mi do głowy tylko wcześniejsze sprawdzenie przez Select, które
nie jest idealnym rozwiązaniem.
1
Dokładnie tak się to robi, najpierw select sprawdzający a dopiero potem twoja akcja.
0
A co należałoby zwrócić kiedy w naszej usłudze wołamy klientem zewnętrzne API i zwróci nam 404 Not Found na podanej encji?
Ale request przyszedł do nas poprawnie, tylko ten zewnętrzny zwrócił błąd .(?)
0
Czarny Kucharz napisał(a):
A co należałoby zwrócić kiedy w naszej usłudze wołamy klientem zewnętrzne API i zwróci nam 404 Not Found na podanej encji?
Ale request przyszedł do nas poprawnie, tylko ten zewnętrzny zwrócił błąd .(?)
Osobiście nadal zwracałbym 404, użytkownik nie koniecznie musi wiedzieć, że pod spodem masz zewnętrzne API czy może bazę danych, zapytał o zasób, nie ma go no to 404 ;).
0
gaUa69 napisał(a):
Czarny Kucharz napisał(a):
A co należałoby zwrócić kiedy w naszej usłudze wołamy klientem zewnętrzne API i zwróci nam 404 Not Found na podanej encji?
Ale request przyszedł do nas poprawnie, tylko ten zewnętrzny zwrócił błąd .(?)Osobiście nadal zwracałbym 404, użytkownik nie koniecznie musi wiedzieć, że pod spodem masz zewnętrzne API czy może bazę danych, zapytał o zasób, nie ma go no to 404 ;).
Ja bym nie zwracal 404, bo to sugeruje, że to client zrobił coś źle a nie zrobił.
Nie wiem czy rodzina 500 + 404 not found w message nie jest sensowniejsze.
0
503 Service Unavailable pasuje do schematu wraz z odpowiednim komunikatem o błędzie w body. Wina leży po stronie serwera, nie klienta, więc zdecydowanie kody z serii 5xx.