Коды состояния REST HTTP для неудачной проверки или недействительного дубликата

Для ошибки проверки ввода: 400 Bad Request + ваше дополнительное описание. Это предложено в книге "RESTful Web Services". Для двойной отправки: 409 Conflict.

Обновление июня 2014 года

Соответствующей спецификацией раньше была RFC2616, в которой использование 400 (Bad Request) описывалось довольно узко, как

Запрос не может быть понят сервером из-за неправильного синтаксиса

Таким образом, можно было бы утверждать, что он не подходит для семантических ошибок. Но не более; с июня 2014 года соответствующий стандарт RFC 7231, который заменяет предыдущий RFC2616, дает использование 400 (Bad Request) в более широком смысле как

сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента

• Не прошла валидация: 403 Forbidden ("Сервер понял запрос, но отказывается его выполнить"). Вопреки распространенному мнению, RFC2616 не говорит "403 предназначен только для неудачной аутентификации", но "403: Я знаю, чего вы хотите, но я не буду этого делать". Это условие может быть связано с аутентификацией, а может и не быть.
• Попытка добавить дубликат: 409 Конфликт ("Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.")

Вам обязательно следует дать более подробное объяснение в заголовках и/или теле ответа (например, с помощью пользовательского заголовка - X-Status-Reason: Validation failed).

Я рекомендую код состояния 422, "Unprocessable Entity".

11.2. 422 Необрабатываемая сущность

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

200,300, 400, 500 все очень обобщенное. Если вы хотите универсальный, 400-это нормально.

422 используется большее количество API и используется даже рельсы из коробки.

Независимо от того, какой код состояния вы выбираете для вашего API, кто-то не согласится. Но я предпочитаю 422, потому что я думаю, что '400 + текст статуса' как слишком общее. Также, вы'т воспользовавшись помощью JSON-парсер готов, в отличие от 422 с JSON ответ, это очень явные, и большое количество информации об ошибках могут быть переданы.

Говоря о JSON ответ, я склоняюсь к стандартизации на рельсы ответ об ошибке для этого дела, а именно:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Этот формат идеально подходит для проверки форме, которую считаю наиболее сложный случай для поддержки в плане 'отчетов об ошибках богатство'. Если ваша структура ошибка это, он, вероятно, обрабатывать все ваши ошибки отчетности.

Дубликат в базе данных должна быть 409 конфликт.

Я рекомендую использовать 422 UNPROCESSABLE лица для ошибок валидации.

Я даю больше объяснений кодов 4хх здесь: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

200

Тьфу... (309, 400, 403, 409, 415, 422)... много ответов, пытаясь угадать, спорить и стандартизации, что является лучшим возврата код для успешного запроса HTTP но не вызов REST.

Это неправильно смешать кодов состояния HTTP и остальные коды состояния.

Однако, я видел много реализаций смешивая их, и многие разработчики могут со мной не согласиться.

Коды возврата протокола HTTP касаются самого HTTP-запроса. Вызов REST осуществляется с использованием протокола передачи гипертекста запрос и он работает на более низком уровне, чем сама вызывается метод отдыха. Остальное-это концепция/подход, а его выход-это бизнес/логические результат, в то время как код результата HTTP-это транспорт один.

К примеру, вернувшись на "404 не найдена" Когда вы звоните /пользователи/ это смущает, потому что это может означать:

• Ури, это неправильно (по протоколу HTTP)
• Ни один пользователь не найден (остальное)

на "403 запрещено Доступ запрещен" и может означать:

• Специальное разрешение. Браузеры могут справиться с запросом пользователя/пароль. (Протокол HTTP)
• Неверные права доступа, настроенных на сервере. (Протокол HTTP)
• Вы должны быть заверены (остальное)

И этот список могут продолжить '500 ошибка сервера" и (для Apache/Nginx в ошибку HTTP или бизнес-ограничений, ошибки в остальных) или другие ошибки HTTP и т. д...

Из кода, это's жесткий, чтобы понять, что было причиной неисправности, а по HTTP (транспорт) отказ или отдыхать (логично) отказ.

Если HTTP-запроса физически был успешно выполнен он должен всегда возвращает 200 код, независимо от того, является запись(с) нашли или нет. Потому что Ури ресурс нашли и обрабатывается HTTP-сервер. Да, он может возвращать пустой набор. Можно ли получить пустой веб-страницы с 200 как результата http, верно?

Вместо этого вы можете вернуть 200 HTTP-код с некоторых вариантов:

• "по ошибке" объект в результате JSON если что-то пойдет не так
• Пустой JSON объекта/объекта, если записей не найдено
• Результат типа bool флаг/успех в сочетании с предыдущим вариантов за лучшую управляемость.

Кроме того, некоторые интернет-провайдеры могут перехватить ваши запросы и возвращает HTTP-код 404. Это вовсе не означает, что ваши данные не найдены, но это's что-то неправильно на уровне транспорта.

С Wiki:

В июле 2004, Великобритания, поставщик Telecom БТ группа развернула Cleanfeed содержание блокирующую систему, которая возвращает ошибку 404 на любой запрос содержание определены как потенциально незаконное по интернету смотреть фундамент. Другие провайдеры возврата НТТР 403 на "запрещено" и ошибки в то же самое обстоятельства. Практика использования поддельных ошибок 404 в качестве средства скрыть цензуры также были зарегистрированы в Таиланде и Тунисе. В В Тунисе, где цензура была суровой до революции 2011 года, люди стали осознавать характер поддельные ошибки 404 и создан вымышленный персонаж по кличке "ьquot Аммар 404&; кто представляет себе "невидимой Цензор" по.

Почему бы просто не ответить что-то вроде этого?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google всегда возвращает 200 код состояния в их геокодирования API, то даже если запрос логически завершается: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook всегда возвращают 200 для успешного HTTP-запросы, даже если запрос остальное терпит неудачу: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

Это's простое, коды состояния HTTP для HTTP-запросов. API-интерфейс REST ваша, определение кодов состояния.

Эмбер-данных'адаптер S и ActiveRecord ожидает 422 UNPROCESSABLE Entity в должен быть возвращен с сервера. Так что, если вы'заново клиент написал в Ember.js вы должны использовать 422. Только тогда ДС.Ошибки будут заполняться ошибки. Вы, конечно, можете изменить 422 любой другой код в ваш адаптер.

Код состояния 304 не изменено также приемлемый ответ на повторяющийся запрос. Это похоже на обработку заголовка если-нет-матч через тег объекта.

На мой взгляд, @Piskvor'ы ответ является более очевидным выбором, чтобы то, что я вижу, является намерением оригинальный вопрос, но у меня есть альтернатива, которая также актуальна.

Если вы хотите лечить повторяющийся запрос в виде предупреждения или уведомления, а не как ошибка, а ответ код состояния 304 не изменяется и расположение содержимого заголовок выявления существующих ресурсов будет так же действителен. Когда намерение состоит лишь в том, что существует ресурс, дубликат запрос будет не ошибка, а подтверждение. Запрос не является неправильным, но является просто излишним, и клиент может обратиться к существующему ресурсу.

Другими словами, запрос-это хорошо, но, поскольку ресурс уже существует, то сервер не нужен для выполнения какой-либо дальнейшей обработки.