Вопрос по http-status-codes, http, validation – Подходит ли возврат HTTP 409 для проверки правильности?

10

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

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

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

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

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

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

Damien_The_Unbeliever: Если вы включите это в ответ, я приму это. Matthew Schinckel
Вы запросили информацию для проверки с сервера. Это соответствует. Мне кажется, что успех (с точки зрения HTTP) Damien_The_Unbeliever

Ваш Ответ

4   ответа
0

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

На самом деле, честно говоря, чем больше я думаю об этом, тем лучше ответ 409, который можно использовать как ошибку проверки. Я думаю, что это действительно сводится к мнению, и пока вы последовательны и имеете хорошую документацию, вы можете пойти в любом случае.
В общем, лучше всего обрабатывать ошибки, которые не являются ошибками связи HTTP, с HTTP 200 и каким-либо кодом ошибки в ответе. В противном случае клиент может неправильно интерпретировать ваш ответ как проблему с вашими серверами.
Отправка сообщения 409, когда данные были правильно сформированы, но не прошла проверку бизнес-логики, провалила ваши тесты. Это явно не сбой связи, а ошибка в валидации. Я думаю, что в этом случае ответshould действительно быть 200, но имхо ваше общее заявление вводит в заблуждение. Matthew Schinckel
Я неquite полностью согласен.409 подразумевает (для меня), что мы нормально общались с сервером: но наш запрос привел бы к хранению недопустимых данных (например). Однако в этом случае я согласен с тем, что200 OK должен быть возвращен, так как запрос проверки был обработан нормально. Matthew Schinckel
0

кончанием" Перефразируя ваши слова по этому, по общему признанию, старому вопросу, я хотел бы проголосовать за возвращение статуса 202. Преимущество этого решения в том, что он имеет 2-- "успеха". введите ответ, чтобы тупой клиент не считал его испорченной страницей, и его заявленное назначение в спецификации 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's 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request's 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.
Второй абзац вашей цитаты - это то, что отвлекает меня от202, Известно, прошла ли проверка успешно или успешно. Суть вопроса в том, что запрос был успешным, просто ответ на вопрос, заданный в запросе, был «проверка не пройдена», ed »; (или прошло). Matthew Schinckel
9

422 Unprocessable Entity это соответствующий статус.

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

Рекомендации:

https://tools.ietf.org/html/rfc4918#section-11.2 http://developer.github.com/v3/#client-errors https://stackoverflow.com/a/2657624/247702 http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error
Я думаю, что вы пропустили ту часть, гдеentire Целью звонка является проведение проверки. В таком случае указание ошибок (когда запрос был правильно сформирован и мы могли выполнить запрошенную проверку) кажется неправильным.
@Damien_The_Unbeliever Я все еще не думаю, что возвращение 200, когда есть ошибки проверки, является хорошим способом сделать это. Вам все еще нужно проанализировать содержимое, чтобы узнать, была ли проверка успешной или нет.
@Stijn Да, это была моя забота. Однако сам запрос выполнен успешно: он просто недействителен. Matthew Schinckel
22

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

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

Этот ответ продолжает получать отрицательные отзывы, и я не совсем уверен, почему (кажется, что ни один из нижестоящих не оставил никаких комментариев). Благодаря значительному количеству обратной связи с ФП мы установили, чтоentire смысл этого запроса / ответа заключался в выполнении проверки. Сервер получил запрос, он выполнил проверку, которую он запрашивал, и возвратил результаты этого процесса проверки вызывающей стороне.

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

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

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

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

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

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

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

409 - это другая ситуация, когда данные действительны и обрабатываются, но действие было отклонено. В этом случае мы хотим знать, безопасно ли продолжать. Я, вероятно, предпочел бы выполнить желаемое действие и затем вернуть ошибки, если оно не может быть завершено, но это необходимо указать после изменений, приведших к «окончательному». действие, если мы готовы выполнить указанное действие. Matthew Schinckel
Я не предлагал использовать для этого 403, просто приводил примеры, которые не соответствуют вашему утверждению. Извиняюсь за путаницу.
-1 403 Forbidden The server understood the request, but is refusing to fulfill it. а также410 Gone The requested resource is no longer available at the server and no forwarding address is known. две ошибки, когда запрос был правильно сформирован и правильно обработан.
Кроме того, как бы вы различалиdata has been saved а такжеdata is invalid? Чтение контента сделает бессмысленным использование кодов состояния. Существует множество дискуссий по этому поводу для API REST, и до сих пор я не видел ни одного, который предлагал бы возврат200 OK.
@Stijn. Из моего прочтения исходного вопроса эта проверка не проводилась до дальнейшей обработки их в рамках той же операции. Эта служба (конечная точка) имеет одну цель - "пожалуйста, выполните некоторую проверку для меня". Если оноhas выполнить проверку (независимо от того, каков будет результат), когда она выполнила всю работу, которую должна была выполнить. этоnot отказ от обслуживания, поэтому 403 кажется неправильным.

Похожие вопросы