Kody statusu HTTP są pogrupowane w pięć klas według pierwszej cyfry, a wybór właściwego pozwala klientom reagować poprawnie bez parsowania ciała odpowiedzi.
2xx Success — the request worked
3xx Redirection — further action / resource moved
4xx Client error — the caller did something wrong
5xx Server error — the server failed
2xx
200 OK — ogólny sukces (GET, PUT, PATCH).201 Created — utworzono zasób (zwróć nagłówek Location).202 Accepted — przyjęto do przetwarzania asynchronicznego, jeszcze nieukończone.204 No Content — sukces bez ciała (częste dla DELETE).4xx
400 Bad Request — zniekształcona składnia lub nieprawidłowe dane wejściowe.401 Unauthorized — nieuwierzytelniony (brak/nieprawidłowe poświadczenia).403 Forbidden — uwierzytelniony, ale bez uprawnień.404 Not Found — zasób nie istnieje.409 Conflict — konflikt z bieżącym stanem (np. zduplikowany e-mail).422 Unprocessable Entity — poprawnie sformowane, ale nie przechodzi walidacji.429 Too Many Requests — ograniczono liczbę żądań (rate limited).5xx
500 Internal Server Error — nieoczekiwana usterka serwera.503 Service Unavailable — tymczasowo niedostępny/przeciążony.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
Kluczowe rozróżnienie, które drążą rozmówcy: 401 („kim jesteś?") vs 403 („znam cię, ale nie"), oraz 400 (zła składnia) vs 422 (poprawna składnia, nieprawidłowe dane).
Kody statusu to główny sygnał w odpowiedzi REST — klienci, proxy, monitoring i logika ponawiania wszystko od nich zależy, więc poprawne ich stosowanie jest niezbędne dla interoperacyjności. Częsta wpadka to zwracanie 200 OK z ciałem { "error": ... }: zmusza to każdego klienta do parsowania ciała, by wiedzieć, czy wywołanie się powiodło, psuje ogólne narzędzia HTTP i ukrywa awarie przed monitoringiem. Precyzyjne kody napędzają też automatyczne zachowanie: 429 lub 503 mówi dobrze zbudowanemu klientowi, by się wycofał i ponowił, podczas gdy 4xx mówi „nie ponawiaj, napraw żądanie". Rozmówcy używają tego pytania, by sprawdzić, czy rozumiesz HTTP jako kontrakt, a nie głupi transport, i czy poprawnie rozróżniasz subtelne pary (401/403, 400/422) — znak rozpoznawczy kogoś, kto budował i konsumował prawdziwe API.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj