Powiedzmy, że mam tabele z produktami i kategoriami. Przy dodawaniu nowego produktu użytkownik musi wybrać kategorię produktu. Przed zapisaniem produktu w bazie następuje sprawdzenie, czy kategoria (Id) istnieje. Co powinienem zwrócić, jeśli kategoria nie istnieje: NotFound czy BadRequest?
0
2
BadRequest dla mnie. Kontrakt endpointa jest taki, że możesz dodać produkt dla kategorii jeśli ona istnieje. W odpowiedzi zwrotnej powinna być informacja że nie ma kategorii. Używaj ustandaryzowanego formatu odpowiedzi. (Np json z polem errorDetails/errors jako lista stringów lub kodów jeśli takie macie zamiast plain textu)
0
A co w takim razie zwrócić, jeśli przy updacie produktu okazuje się, że produkt nie istnieje? Też BadRequest?
2
Nie, wtedy NotFound.
Jeśli sytuacja dotyczy zasobu, na którego końcówkę strzelasz to NotFound.
Ale w sumie zależy od praktyki. Z drugiej strony problem z tym podejściem jest taki, że NotFound ma teraz 2 znaczenia. Jak nie ma zasobu i jak nie ma takiej końcówki. Mimo to i tak NotFound bym tu rzucal.
0
nobody01 napisał(a):
A co w takim razie zwrócić, jeśli przy updacie produktu okazuje się, że produkt nie istnieje? Też BadRequest?
Dajesz 304.
Dlatego że to nie jest walidacja inputa tylko asercja (wyjątek) efektu ubocznego jak np. problem współbieżności.
2
nobody01 napisał(a):
A co w takim razie zwrócić, jeśli przy updacie produktu okazuje się, że produkt nie istnieje? Też BadRequest?
Wszystko jest ładnie rozrysowane tutaj: https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html
Nie ma resource, zwracasz 404.
._. napisał(a):
Dajesz 304.
Dlatego że to nie jest walidacja inputa tylko asercja (wyjątek) efektu ubocznego jak np. problem współbieżności.
Jakiego efektu ubocznego, jak tu zasób nie istnieje. Poczytaj do czego 304 służy: https://httpstatuses.com/304
0
Jakiego efektu ubocznego, jak tu zasób nie istnieje. Poczytaj do czego 304 służy: https://httpstatuses.com/304
No tak, racja.
A jeśli ktoś w komendę modyfikacji produktu wpisał kategorie, która nie istnieje?
0
No jak dla mnie, to jeżeli ktoś wpisał, to zawsze to jest bad request, bo złe dane przyszły od użytkownika.
0
A to nie jest tak, że Bad Request sugeruje "popraw to, co wpisałeś, bo nie przeszło walidacji". Jeśli ktoś wpisał kategorie, która nie istnieje, to znaczy, że klient, źle działa i jest to wyjątek, który można zaznaczyć innym kodem.
Raczej zaznaczył a nie wpisał.
1
No i dokładnie z tym masz do czynienia w tej sytuacji. Ktoś podał nieistniejącą kategorię, więc niech ją poprawi, bo to nie są poprawne dane wejściowe. Z punktu widzenia API to jest bad request.
Druga rzecz, to to, czemu w ogóle użytkownik mógł wysłać żądanie z wybraną nieistniejącą kategorią do API. Ale to już pytanie to teamu, który zepsuł aplikację kliencką.
0
Masz rację, 304 to bardziej jakby baza nie istniała albo jakiś problem po stronie aplikacji na serwerze.
0
._. napisał(a):
A to nie jest tak, że Bad Request sugeruje "popraw to, co wpisałeś, bo nie przeszło walidacji". Jeśli ktoś wpisał kategorie, która nie istnieje, to znaczy, że klient, źle działa i jest to wyjątek, który można zaznaczyć innym kodem.
Raczej zaznaczył a nie wpisał.
A od nieprzechodzącej walidacji nie jest czasem 422?
400 leci jak dostaniesz flaki, których nie jesteś w stanie zainterpretować
0
Chyba niekoniecznie, w ogóle 422 jest lekko bez sensu po ostatnich zmianach w specyfikacji.