REST API status w przypadku błędu

1

Witam,

Jaki kod odpowiedzi HTTP powinien otrzymać request, który został obsłużony po stronie aplikacji ale wystąpiły pewne błędy uniemożliwiające jego prawidłowe przeprocesowanie.

Przykład:

Request, który aktualizuje ceny produktów w sklepie.
Jeśli:

  • produkt istnieje, to zwracam kod odpowiedzi 200
  • produkt nie istnieje, to powinienem zwrócić 200 + w response wstawić np. błąd jaki wywaliła aplikacja, czy może bawić się ze statusami z grupy 4XX?

Jakie macie dobre praktyki w tym temacie?

4
  1. W drugim zdecydowanie 404. Inaczej to nie jest REST, ale inna technolgia (np GraphQL )

  2. Nie wyważasz otwartych drzwi? Kody dla REST są powszechnie udokumentowane (3xx, 4xx, 5xx) - o ile to nadal jest (moje słowo) nie zgwałcony REST (bo wg mojego prywatnego rankingu wiele jest "zgwałconego")

2

Skoro GET /api/product/<id> zwróci 404 (bo nie ma produktu) to PUTPATCH /api/product/<id> tym bardziej powinien.

EDIT: uwagi niżej

3

Poczytaj o statusach HTTP, na Wiki masz pełną listę

0

Dziękuję,

Jest to jak najbardziej zbieżne z informacjami z innego źródła. :)

2

Z tym że warto zwrócić uwagę (na przyszłość) że nie zawsze "nie znaleziono" = 404. Przykład: jeśli implementujesz szukajkę, to w przypadku nie znalezienia rezultatu wg danych kryteriów 404 nie ma sensu, bo zapytanie się powiodło i jego rezultatem jest pusty zbiór.

3
Wiara czyni cuda napisał(a):
  • produkt istnieje, to zwracam kod odpowiedzi 200
  • produkt nie istnieje, to powinienem zwrócić 200 + w response wstawić np. błąd jaki wywaliła aplikacja, czy może bawić się ze statusami z grupy 4XX?

Jakie macie dobre praktyki w tym temacie?

Zawsze zwracam zarówno sensowny kod HTTP błędu oraz jakiś komunikat. Czasem także unikalny (w ramach API) kod błędu, aby ludzie od UI mogli to np. przetłumaczyć dla wersji językowej.

Mniej więcej idzie to tak:
201 - jeśli utworzono nowy zasób;
202 - jeśli wywołano jakąś długotrwałą operację, która nie zwraca wyniku od razu;
204 - jeśli usunięcie się powiodło;
200 - w pozostałych przypadkach powodzenia;
400 - jeśli użytkownik spieprzył;
401, 403 - wiadomo, to nawet często do aplikacji nie wchodzi; (edytowane, bo się w komentarzach czepiają)
404 - nie znaleziono;
408 - jeśli jakiś wywoływany synchronicznie zewnętrzny zasób nie odpowie w założonym czasie, i jeśli jest wymóg odróżnienia tego od 500;
409 - operacja nieprawidłowa dla danego zasobu, dla Twojego przykładu to np. zmiana ceny wycofanego produktu;
415 - nieprawidłowa wersja endpointu;
500 - każdy inny błąd, z którym użytkownik nie może niczego zrobić.

Delor napisał(a):

Skoro GET /api/product/<id> zwróci 404 (bo nie ma produktu) to PUT /api/product/<id> tym bardziej powinien.

PUT nie może zwrócić 404, co najwyżej 201.

3

A co z PUT na zasobie który nie istnieje? 404 jak dla mnie.

2

No jak nie istnieje, to PUT ten zasób tworzy i zwraca 201.

0
somekind napisał(a):

No jak nie istnieje, to PUT ten zasób tworzy i zwraca 201.

Dla PUT podajesz ID, żeby było wiadomo co ma być zmodyfikowane.
Czyli jeśli zrobię /endpoint/id/cztery_litery to ma stworzyć taką encje z takim ID? No chyba nie?
To samo jeśli jest sytuacja z inkrementacja ID i ostatnie masz 10, a tu ktoś nagle wpisze 1000.

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