Какие ошибки у статусов кода 400?

Общие ошибки HTTP 400 и их спецификация

Статус 400 (Bad Request) является общим клиентским кодом ошибки, указывающим на то, что сервер не может или не желает обработать запрос из-за чего-то, воспринимаемого как ошибка клиента (например, неправильный синтаксис, нарушение структуры сообщения или обманчивый маршрут запроса). Это один из наиболее распространенных статусов для ошибок валидации данных на стороне клиента. В рамках этого кода существует множество конкретных сценариев ошибок, которые могут быть дополнительно детализированы с помощью тела ответа, заголовков или (в некоторых API) расширенных статусов.

Основные категории и примеры ошибок для 400 Bad Request

1. Ошибки синтаксиса и формата данных

    *   **Неверный JSON или XML в теле запроса:** Неправильный синтаксис, отсутствующие закрывающие скобки, недопустимые символы.
    *   **Неверный формат данных в полях:** Например, отправка строки `"abc"` в поле, ожидающее число, или отправка даты в формате, не соответствующем `ISO 8601`.
    *   **Ошибки в структуре запроса:** Например, отсутствие обязательного поля `email` в запросе регистрации.

```json
// Пример неправильного JSON (отсутствует закрывающая скобка)
{
  "name": "John",
  "age": 30
// Ошибка: отсутствует '}'
```

```json
// Пример ответа сервера с описанием ошибки
{
  "statusCode": 400,
  "message": "Bad Request",
  "errors": [
    {
      "field": "age",
      "message": "Expected number, but received string 'thirty'"
    }
  ]
}
```

2. Ошибки валидации параметров запроса

    *   **Недопустимые или отсутствующие обязательные параметры (query, path, header):** Например, запрос `/api/users?page=` без значения для `page`.
    *   **Параметры с недопустимым значением:** `page=-1` (ожидается положительное число).
    *   **Неверная комбинация параметров:** Использование параметров, которые конфликтуют друг с другом.

1. Ошибки заголовков (Headers)

    *   **Отсутствие обязательных заголовков:** Например, `Content-Type: application/json` для POST запроса.
    *   **Неверное значение заголовка:** `Content-Type: text/html` вместо `application/json`.
    *   **Заголовки с неправильным форматом:** Например, неверный формат в `Authorization` или `Accept`.

1. Ошибки, связанные с размером или объемом данных

    *   **Тело запроса слишком большое:** Сервер может ограничивать максимальный размер принятого тела (например, 10MB).
    *   **Пустой тело запроса при ожидании данных:** Отправка POST/PUT запроса без тела, когда API требует данные.

1. Ошибки бизнес-логики и семантической валидации (часто возвращаются с 400, хотя иногда используют 422)

    *   **Попытка создать дублирующий ресурс:** Например, регистрация с email, который уже существует в системе.
    *   **Несоответствие данных бизнес-правилам:** Например, попытка установить дату рождения в будущем или сумму платежа ниже минимальной.
    *   **Неправильный тип операции с данными:** Попытка отправить данные для обновления (`PUT`) в формате, предназначенном для создания (`POST`).

Спецификация: 400 vs 422 Unprocessable Entity

Часто возникает вопрос о различии между 400 Bad Request и 422 Unprocessable Entity (из спецификации RFC 4918 для WebDAV). Хотя 422 не является частью основного HTTP/1.1 (RFC 7231), он широко используется в REST API для более точной индикации ошибок.

• 400 Bad Request: Чаще указывает на синтаксические ошибки, проблемы с структурой HTTP-запроса, отсутствие обязательных заголовков, нечитаемое тело. "Сервер не понял запрос изза некорректного формата".
• 422 Unprocessable Entity: Чаще указывает на семантические ошибки в данных, которые сервер понял, но не может обработать из-за логических нарушений. Данные синтаксически корректны, но недействительны по содержанию. Например, передача несуществующего ID связанной сущности или нарушение уникальности поля.

// Пример типичного ответа 422
{
  "statusCode": 422,
  "message": "Unprocessable Entity",
  "errors": [
    {
      "field": "email",
      "message": "Email 'john@example.com' is already taken."
    },
    {
      "field": "relatedProjectId",
      "message": "Project with ID 9999 does not exist."
    }
  ]
}

Практические рекомендации для фронтенд-разработчика

• Обработка на клиенте: При получении статуса 400 необходимо не просто показывать общее сообщение "Bad Request", а анализировать тело ответа (которое часто содержит массив конкретных ошибок) и предоставлять пользователю детализированную информацию. Например: "Поле 'Email' должно быть корректным адресом".
• Предварительная валидация: Чтобы минимизировать 400 ошибки, реализуйте строгую валидацию данных на стороне клиента перед отправкой запроса. Проверяйте типы данных, обязательные поля, форматы (email, phone), допустимые диапазоны.
• Анализ структуры ошибок: Узнайте формат тела ошибки от вашего backend API (стандартные форматы включают application/problem+json или собственные структуры с полями errors, field, message). Напишите универсальный обработчик ошибок.
• Логирование для разработки: В режиме разработки логируйте полный ответ ошибки 400 (включая тело) в консоль или специальный интерфейс для быстрого выявления проблем.

// Пример обработки ответа с ошибкой 400 на фронтенде
async function submitUserData(formData) {
  try {
    const response = await fetch('/api/users', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(formData),
    });

    if (!response.ok) {
      const errorBody = await response.json();
      // Предполагаем стандартизированный формат ошибки
      if (errorBody.errors && Array.isArray(errorBody.errors)) {
        // Агрегируем ошибки по полям для отображения пользователю
        const fieldErrors = {};
        errorBody.errors.forEach(err => {
          fieldErrors[err.field] = err.message;
        });
        throw new ValidationError('Invalid form data', fieldErrors);
      }
      throw new Error(`HTTP ${response.status}: ${errorBody.message || 'Bad Request'}`);
    }
    return await response.json();
  } catch (error) {
    if (error instanceof ValidationError) {
      // Отображение ошибок рядом с соответствующими полями формы
      displayFormErrors(error.fieldErrors);
    } else {
      showToast('An unexpected error occurred.');
    }
  }
}

// Пример класса для ошибок валидации
class ValidationError extends Error {
  constructor(message, fieldErrors) {
    super(message);
    this.name = 'ValidationError';
    this.fieldErrors = fieldErrors;
  }
}

Таким образом, статус 400 Bad Request является важным сигналом для фронтенд-разработчика о том, что запрос, отправленный с клиента, некорректен. Глубокая обработка и анализ этих ошибок напрямую влияют на пользовательский опыт (UX), позволяя быстро и точно исправлять введенные данные, и на качество разработки, помогая выявлять проблемы в клиентской логике формирования запросов.