Возвращает HTTP 409, подходящий для проверки проверки?

У меня есть служба, где некоторые правила проверки должны быть проверены до того, как будет выполнена конкретная операция.

Например, клиент не должен создавать отчеты для печати, если все правила проверки не выполняются.

Однако у отдельного клиента может не быть всей необходимой информации (этот пользователь может иметь доступ только к подмножеству данных, которые используются для определения успеха проверки), поэтому запрос должен быть отправлен на сервер: в основном "является thing, действительным между start и finish".

Ответ будет либо своего рода токеном, который указывает VALID: FEEL FREE TO CONTINUE, либо список причин отказа проверки, которые могут быть представлены пользователю.

Очевидно, что успешная проверка вернет значение 200 OK. Но я не чувствую, что код статуса успеха подходит для отказа проверки. Я склоняюсь к 409 Conflict, но я использовал это только для отклонения PUT или POST. Действительно ли (snicker) имеет ошибку проверки, указанную 409, или есть лучший способ?

Примечание: выполняемое действие не выполняется на сервере, поэтому пропустить эту проверку и просто выполнить действие с помощью 403 в случае запрещенного действия не является вариантом.

Ответ 1

Вы отправили запрос на сервер, чтобы он выполнил проверку. Он успешно выполнил указанную проверку. С точки зрения HTTP, запрос был хорошо сформирован и правильно обработан сервером.

Итак, я бы сказал, что неверный код ошибки HTTP будет неверным.

Этот ответ продолжает получать downvotes, и я не совсем уверен, почему (ни один из downvoters, похоже, не оставляет никаких комментариев). Через справедливое количество назад и вперед с OP мы установили, что вся точка этого запроса/ответа должна была выполнять валидацию. Сервер получил запрос, он выполнил проверку, которую ему было предложено выполнить, и он возвратил результаты этого процесса проверки вызывающему.

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

Сервер понял запрос.

Запрос был действительным (с точки зрения HTTP).

Сервер может обрабатывать запрос.

Сервер выполнил 100% активности, к которой он предназначался, и возвращает результаты, которые были обработаны при обработке запроса.

И вот почему, как я уже сказал, я не считаю, что код ошибки HTTP подходит.

т.е. представьте, что сервер предоставляет конечную точку, которая проверяет адреса электронной почты (для любой конкретной формы вы хотите сказать, что валидация может быть выполнена). Он получает запрос "validate [email protected]", и он дает ответ: "Я взглянул на этот адрес электронной почты, и я хотел бы, чтобы вы сказали пользователю, что я не могу получить действительный ответ DNS для недействительных .org". Если люди не думают, что ответ здесь будет правильным, я бы хотел понять их рассуждения.

Ответ 2

Пока он определен в предлагаемом стандарте, 422 Unprocessable Entity является подходящим статусом.

Код статуса 422 (необработанная сущность) означает сервер понимает тип содержимого объекта запроса (следовательно, 415 (Неподдерживаемый тип носителя) не подходит), и синтаксис объекта запроса является правильным (таким образом, 400 (неудачный запрос) код состояния не подходит), но не смог обработать содержащиеся инструкции.

Например, это условие ошибки может возникнуть, если XML тело запроса содержит хорошо сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.

Литература:

Ответ 3

Если состояние вашего ресурса HTTP находится где-то "между запуском и завершением", чтобы перефразировать ваши слова по этому, по общему признанию, более старую проблему, я хотел бы включить голосование для возвращения статуса 202. Он имеет то преимущество, - ответ типа "успех", поэтому более дюжий клиент не будет считать его сломанной страницей, и заявленная цель в спецификации HTTP 1.1 звучит так, как вы хотите (хотя многие определения кода состояния очень неоднозначны).

Ссылка на спецификацию

Выдержки:

202 Accepted

The request has been accepted for processing, but the processing has not been 
completed. The request might or might not eventually be acted upon, as it 
might be disallowed when processing actually takes place...

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.

Ответ 4

Как это часто бывает, трудно дать точный совет, не зная точно, что вы делаете, как и почему и т.д. Например:

У меня есть служба, где некоторые правила проверки должны быть проверены перед должна выполняться определенная операция.

Служба обслуживает локальный код? Если это так, вы должны выбросить исключение в локальный код или вернуть что-то нормальное.
Это связано с запросом API? Если это так, то я не могу понять, почему вы выполняете проверку по отдельному вызову REST, а не делаете все это в одном запросе.

Однако отдельный клиент может не иметь всех необходимых информация (этот пользователь может иметь доступ только к подмножеству данных который используется для определения успешности проверки), поэтому запрос должен быть отправлено на сервер: в основном "это вещь действительная между началом и отделка".

Я делаю предположения, например, ради, но, например, вы можете просто позволить им сделать запрос, который они сделали бы, если бы у них были все необходимые данные и т.д., И подтвердить в этот момент.

Ответом может быть какой-то токен, обозначающий VALID: Не стесняйтесь продолжать, или список причин неудачи проверки, что может быть представлен пользователю.

Вот почему я предлагаю то, что у меня есть, так как ваш текст гласит:

Отправить запрос в API, API выполняет валидацию и возвращает ответ;
Если ответ отображается как действительный, то пользователь отправляет следующий ответ, чтобы выполнить реальную задачу;
Если ответ показывает недействительный, то пользователь должен что-то сделать и повторить, пока он не получит действительный ответ, тогда он все равно должен сделать фактическое действие;

Альтернатива:

Отправить запрос в API, выполнить валидацию, если действительный, сделать вещь, иначе ответ возврата с указанием недопустимого состояния;
Пользователь вносит изменения, и у него снова есть только один запрос на отправку, чтобы выполнить проверку и актуальную вещь;

Примечание: выполненное действие не выполняется на сервере, поэтому пропуская эту проверку, и просто пытаясь действовать, с 403 в случай запрещенного действия - не вариант.

Если это не какой-либо вид удаленного /API-запроса, я бы предложил не использовать HTTP-коды. Это все сделано в одной и той же кодовой базе? Если это так, исключения или bools и т.д. Из вашей проверки, чтобы отправить сообщение пользователю.

Ответ 5

Я думаю, что до тех пор, пока вы не злоупотребляете кодом для чего-то, что оно не предназначено, это действительно сводится к предпочтениям и мнению. 409, вероятно, подходит для отказа в валидации, хотя я думаю, что лично я предпочел бы 200 с ошибкой проверки в качестве ответа. Я думаю, что это упростит разработчикам проверить общие коммуникационные ошибки, такие как 401 или 500, и разобраться с ними, прежде чем им придется беспокоиться о проверке данных, которые они отправили.