Какой HTTP статус должен возвращаться при успешном POST-запросе на создание данных

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

Сам код называют за секунду, поэтому для фронтендера вопрос обычно продолжается: как клиент обрабатывает такой ответ, чем 201 отличается от 200 и 204 и что будет с fetch, если сервер ответил ошибкой.

Как отвечать

Правильный статус: 201 Created. Сервер создал ресурс, в теле обычно возвращает его (с id, датами, вычисленными полями), в заголовке Location его адрес. Соседние варианты:

• 200 OK: допустим, если POST ничего не создал как отдельный ресурс, например поиск или расчёт;
• 202 Accepted: запрос принят, но обработка идёт асинхронно, результат появится позже. Клиенту нужно опрашивать статус или ждать событие;
• 204 No Content: успех без тела.

Теперь фронтенд-часть, ради которой вопрос и задают:

• fetch не отклоняет промис на 4xx и 5xx: проверяйте response.ok (он true для кодов от 200 до 299) или конкретный response.status;
• 204 без тела: вызов response.json() на пустом ответе бросит SyntaxError, тело читают только когда оно есть;
• Location при запросе на другой домен: заголовок не входит в список безопасных, и из JS его не прочитать, пока сервер не отдаст Access-Control-Expose-Headers: Location;
• axios: по умолчанию считает успехом весь диапазон 2xx, а на остальное бросает ошибку.

Хорошо закончить тем, что делать с ответом: взять созданный объект из тела и положить в кеш, чтобы не делать лишний GET. В TanStack Query это setQueryData или invalidateQueries в onSuccess у useMutation.

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

Проверяют строго status === 200. Бэкенд переходит на правильный 201, и форма начинает показывать ошибку на успешном создании.

Оборачивают fetch в try/catch и считают, что ошибки сервера попадут в catch. Туда попадают только сетевые сбои, а 400 и 500 приходят как обычный ответ.

После создания перезапрашивают весь список, хотя сервер уже вернул созданный объект. На длинных списках это лишняя задержка и мигание интерфейса.