Какие знаешь коды состояния HTTP?

Коды состояния HTTP: классификация и применение

Коды состояния HTTP (HTTP Status Codes) — это стандартизированные трехзначные числа, которые сервер возвращает клиенту в ответ на его запрос. Они являются неотъемлемой частью протокола HTTP/HTTPS и служат для быстрой передачи информации о результате обработки запроса. Все коды разделены на пять классов, определяемых первой цифрой.

1xx: Информационные коды (Informational)

Указывают, что запрос принят и обработка продолжается. Клиент должен ожидать окончательного ответа.

• 100 Continue: Сервер получил заголовки запроса и клиент может продолжать отправку тела запроса.
• 101 Switching Protocols: Сервер соглашается сменить протокол (например, с HTTP на WebSocket).
• 102 Processing (WebDAV): Сервер обрабатывает запрос, но ответ еще не готов.
• 103 Early Hints: Возвращает часть заголовков ответа до того, как основной ответ будет готов (для предварительной загрузки ресурсов).

2xx: Коды успеха (Success)

Сигнализируют об успешном выполнении запроса.

• 200 OK: Стандартный ответ для успешных GET, POST, PUT или DELETE запросов.
• 201 Created: Запрос выполнен, новый ресурс создан (часто после POST). В заголовке Location может быть указан URI созданного ресурса.
• 202 Accepted: Запрос принят, но его обработка еще не завершена (асинхронные операции).
• 204 No Content: Сервер успешно обработал запрос, но не возвращает никакого контента (часто после DELETE или PUT).
• 206 Partial Content: Сервер возвращает часть данных (используется для докачки файлов или потокового видео, заголовок Range).

3xx: Коды перенаправления (Redirection)

Указывают клиенту на необходимость дополнительных действий для завершения запроса.

• 301 Moved Permanently: Запрошенный ресурс навсегда перемещен на новый URI. Браузеры и поисковики обновляют ссылки.
• 302 Found (ранее Moved Temporarily): Ресурс временно доступен по другому URI. Метод запроса при редиректе может измениться на GET.
• 303 See Other: Ответ на запрос находится по другому URI, который следует запросить методом GET.
• 304 Not Modified: Используется для кэширования. Ресурс не изменился с момента последнего запроса (заголовки If-Modified-Since, ETag).
• 307 Temporary Redirect: Аналогичен 302, но гарантирует, что метод запроса (POST/PUT) не изменится при перенаправлении.
• 308 Permanent Redirect: Аналогичен 301, но также гарантирует сохранение метода запроса.

4xx: Коды ошибки клиента (Client Error)

Указывают, что ошибка, вероятно, вызвана клиентом (неверный запрос, отсутствие прав и т.д.).

• 400 Bad Request: Сервер не может обработать запрос из-за синтаксической ошибки (невалидный JSON, некорректные заголовки).
• 401 Unauthorized: Для доступа к ресурсу требуется аутентификация. Заголовок WWW-Authenticate указывает способ аутентификации.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (недостаточно прав, IP в черном списке).
• 404 Not Found: Самый известный код. Сервер не нашел запрашиваемый ресурс.
• 405 Method Not Allowed: Метод запроса (GET, POST и т.д.) не поддерживается для данного URI (заголовок Allow содержит список разрешенных методов).
• 408 Request Timeout: Сервер не дождался полного запроса от клиента в течение установленного времени.
• 409 Conflict: Запрос конфликтует с текущим состоянием сервера (например, попытка создать дублирующий ресурс, конфликт версий при оптимистичной блокировке).
• 429 Too Many Requests: Клиент отправил слишком много запросов за короткое время (защита от DDoS, rate limiting).

5xx: Коды ошибки сервера (Server Error)

Указывают на сбой на стороне сервера при обработке валидного запроса.

• 500 Internal Server Error: Общий код для непредвиденных внутренних ошибок сервера (исключение в коде, сбой конфигурации).
• 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
• 502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недопустимый ответ от вышестоящего сервера.
• 503 Service Unavailable: Сервер временно не может обрабатывать запросы из-за перегрузки или технического обслуживания. Заголовок Retry-After может указать время ожидания.
• 504 Gateway Timeout: Сервер, выступая в качестве шлюза, не дождался ответа от вышестоящего сервера.

Практическое использование в C# Backend (ASP.NET Core)

В ASP.NET Core для возврата кодов состояния используются методы контроллера и класс ControllerBase.

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _service;

    // 200 OK / 404 Not Found
    [HttpGet("{id}")]
    public async Task<ActionResult<ProductDto>> GetProduct(int id)
    {
        var product = await _service.GetByIdAsync(id);
        if (product == null)
        {
            return NotFound(); // Возвращает 404
        }
        return Ok(product); // Возвращает 200 с телом
    }

    // 201 Created
    [HttpPost]
    public async Task<ActionResult<ProductDto>> CreateProduct(ProductCreateDto dto)
    {
        var createdProduct = await _service.CreateAsync(dto);
        // Первый параметр - имя маршрута, второй - параметры для него, третий - тело ответа
        return CreatedAtAction(nameof(GetProduct), new { id = createdProduct.Id }, createdProduct);
    }

    // 204 No Content
    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteProduct(int id)
    {
        await _service.DeleteAsync(id);
        return NoContent(); // 204
    }

    // 400 Bad Request с моделью ошибки (автоматически при [ApiController])
    // 409 Conflict
    [HttpPut("{id}")]
    public async Task<IActionResult> UpdateProduct(int id, ProductUpdateDto dto)
    {
        try
        {
            await _service.UpdateAsync(id, dto);
            return NoContent();
        }
        catch (ConcurrencyException)
        {
            return Conflict("Запись была изменена другим пользователем."); // 409
        }
    }

    // Возврат произвольного кода
    [HttpPost("custom")]
    public IActionResult CustomAction()
    {
        // Например, для 418 I'm a teapot (шутливый код RFC 2324)
        return StatusCode(418, "Я - чайник.");
    }
}

Ключевые принципы для бэкенд-разработчика:

1. Семантическая корректность: Использовать коды в соответствии со стандартом. Не возвращать 200 OK при ошибке.
2. Безопасность: Не раскрывать в телах ответов с ошибками 5xx внутренние детали реализации (стек-трейсы, имена серверов) в production.
3. Обработка на клиенте: Клиентское приложение должно корректно реагировать на разные классы кодов (например, повторять запрос при 503 с Retry-After, запрашивать аутентификацию при 401).
4. Мониторинг: Коды 4xx (особенно 400, 404) помогают выявлять проблемы в клиентских приложениях, а 5xx — критические сбои в серверной логике, требующие немедленного внимания разработчиков.

Понимание и правильное применение HTTP-кодов состояния — это фундаментальный навык, который напрямую влияет на надежность, понятность и отказоустойчивость API.