Какие группы кодов ответа от сервера существуют

Что проверяют

Базовое знание HTTP и то, как оно ложится на net/http: какой код вернёт обработчик, если вы ничего не указали, и как клиент Go ведёт себя на ошибках. Следом обычно спрашивают разницу между 401 и 403 или какой код отдать на невалидный JSON.

Как отвечать

Групп пять, первая цифра задаёт класс:

• 1xx, информационные: 100 Continue для заголовка Expect: 100-continue, 101 Switching Protocols при переходе на WebSocket, 103 Early Hints;
• 2xx, успех: 200 OK, 201 Created с заголовком Location, 202 Accepted для асинхронной обработки, 204 No Content без тела;
• 3xx, перенаправления: 301 и 308 постоянные, 302 и 307 временные, причём 307 и 308 не дают сменить метод. 304 Not Modified отвечает на условный запрос с ETag;
• 4xx, ошибка клиента: 400 запрос не разобран, 401 нет аутентификации, 403 прав нет, 404, 409 конфликт состояния, 422 данные не прошли валидацию, 429 превышен лимит;
• 5xx, ошибка сервера: 500, 502 плохой ответ апстрима, 503 сервис временно недоступен, 504 апстрим не ответил вовремя.

Дальше привяжите к Go. В обработчике коды берут из констант вроде http.StatusCreated, а w.WriteHeader зовут до первого w.Write: если сначала записать тело, уйдёт 200, а поздний вызов лишь даст в логе superfluous response.WriteHeader call. На клиенте http.Client не возвращает ошибку на 404 или 500, err бывает при сетевых сбоях, поэтому resp.StatusCode проверяют явно и всегда закрывают resp.Body. Редиректы клиент проходит сам, по умолчанию до десяти подряд, политика меняется через CheckRedirect.

Где спотыкаются

Путают 401 и 403. Первый про «кто вы», второй про «вам сюда нельзя».

Считают, что err == nil означает успешный ответ, и разбирают тело 500 как нормальный JSON.

Отдают 200 с полем "error" в теле на любые сбои. Мониторинг, ретраи и балансировщик ориентируются на код, и такие ошибки для них невидимы.