HTTP-статус при POST с неверными данными (используется идентификатор ресурса, который не существует)

Question

Какой будет правильный статус HTTP для возврата , когда я выполняю запрос POST для создания нового пользователя, но один из его параметров неверен - идентификатор компании, который я включаю в данные пользователя, нене существует в базе данных.

Данные POST: {имя пользователя: 'newuser', возраст: 99, company_id: 34 }

компания с идентификатором34 не существует в базе данных.

Я думал, может ли это быть:

• 400, недопустимые данные, но это действительный, но несуществующий идентификатор
• 404 - но не очень понятно, какой ресурс не существует
• 409, потому что это своего рода конфликт, и пользователь может разрешить его, изменив идентификатор компании
• 422?
• или 500 - потому что это своего рода ошибка базы данных, в то время как несуществующие идентификаторы там не допускаются

Answer 1

404 Not Found - это проблемный статус для возврата на POST запрос.Это означает, что ресурс, которому вы отправляете запрос, не существует;вызывающий абонент неверно указал URL.

Наиболее очевидный (и общий) ответ: 400 Bad Request

Это просто указывает на то, что с вашим запросом что-то не так (ошибка заключается в том, что вызывающий абонент несервер), а затем выразить конкретные детали того, что пошло не так в вашем теле ответа.Как правило, именно так обрабатывается проверка запроса.

---

идеальный ответ - сделать так, чтобы вы добавили пользователя, отправив запрос в компанию, членом которой он является:

POST /company/34
Content-Type: application/json
{
    "username": "newuser",
    "age": 99
}

Это означает, что вызывающий должен найти действительный ресурс company для отправки запроса.Если company/34 не существует, то ответ 404 Not Found подходит;Вы пытались добавить пользователя в компанию, которая не существует.

Это означает, что ваш API должен быть структурирован с семантикой ресурсов, а пользователь должен принадлежать только одной компании.

Answer 2

400 или 422

Прежде всего, помните, что это ошибка клиента , поэтому 5xx коды состояния не подходятВот.Вам следует выбрать код состояния 4xx.

Наиболее очевидные варианты: 400 и 422:

• Если JSON синтаксически недействителен , верните 400.
• Если JSON синтаксически действителен , но его содержимое недопустимо , возвращает 422, чтобы указать, что объект запроса не может быть обработан сервером.

См. Следующую цитату из RFC 4918 (для вашей ситуации просто прочитайте JSON , когда написано XML ):

11.2.422 Unprocessable Entity

Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type)неуместно), и синтаксис объекта запроса является правильным (таким образом, код состояния 400 (неверный запрос) неуместен), но не смог обработать содержащиеся в нем инструкции.Например, это условие ошибки может возникать, если тело запроса XML содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML.

Аналогичная ситуация была рассмотрена в этом ответ .

---

Например, GitHub API v3 также возвращает 422, если содержимое полезной нагрузки содержит недопустимые значения (носинтаксически действителен):

Существует три возможных типа ошибок клиента при вызовах API, которые получают тела запросов:

1. Отправка неверного JSON приведет к 400 Bad Request ответ.[...]

2. Отправка неверного типа значений JSON приведет к 400 Bad Request response.[...]

3. Отправка недействительных полей приведет к ответу 422 Unprocessable Entity.[...]

---

Майкл Кропат собрал набор диаграмм , это довольно проницательно, когда дело доходит довыбирая наиболее подходящий код статуса.См. Следующую диаграмму для 4xx кодов состояния:

Answer 3

Здесь эта картинка очень хорошая, и я использовал ее много раз.

Какой код я должен вернуть?

Я бы пошел с 404. Ресурс может существовать (не ошибка формата), но его просто нет (и, следовательно, он не может быть найден).