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

Я создаю приложение с API на основе REST и дошел до точки, где я указываю коды состояния для каждого запроса.

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

Я просмотрел http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html но ни один из них не кажется правильным.

существует ли общая практика при отправке статуса коды?

8 ответов


для ошибки проверки ввода:400 Плохой Запрос + ваше описание. Об этом говорится в книге "RESTful Web Services". Для двойной отправки:409 конфликт


Обновление Июнь 2014

соответствующая спецификация была адресу rfc2616, который дал использование 400 (плохой запрос) довольно узко, как

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

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

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


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

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


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

11.2. 422 Unprocessable Лица

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


200,300, 400, 500 все очень обобщенное. Если вы хотите generic, 400 в порядке.

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

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

говоря о ответе JSON, я склонен стандартизировать ответ на ошибку Rails для этого случая, который:

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

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


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

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

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


200

тьфу... (309, 400, 403, 409, 415, 422)... много ответов, пытающихся угадать, спорить и стандартизировать, что является лучшим кодом возврата для успешный http-запрос но неудачный вызов rest.

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

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

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

например, возврат "404 не найден" при вызове /users / путают, потому что это может означать:

  • URI неверен (HTTP)
  • нет пользователей найдено (отдых)

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

  • требуется специальное разрешение. Браузеры могут справиться с этим, спросив пользователя/пароль. (HTTP)
  • неверные разрешения доступа, настроенные на сервере. (HTTP)
  • вам необходимо пройти аутентификацию (REST)

и список может продолжаться с "500 Server error" (Apache / Nginx HTTP thrown error или ошибка бизнес-ограничения в REST) или другие ошибки HTTP так далее...

из кода трудно понять, что было причиной сбоя, http (транспортный) сбой или REST (логический) сбой.

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

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

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

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

С Wiki:

в июле 2004 года британский телекоммуникационный провайдер BT Group развернул Cleanfeed система блокировки контента, которая возвращает ошибку 404 на любой запрос контент, идентифицированный как потенциально незаконный Internet Watch Основа. Другие интернет-провайдеры возвращают HTTP 403" запрещенную " ошибку в том же обстоятельства. Практика использования поддельных ошибок 404 в качестве средства скрывать цензуры также были зарегистрированы в Таиланде и Тунисе. В Тунис, где цензура была жесткой до революции 2011 года, люди узнали о природе фальшивых 404 ошибок и создали воображаемый персонаж по имени "Аммар 404", который представляет "невидимый цензор."

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

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

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


Код Состояния 304 Не Изменено также сделает приемлемый ответ на дублирующий запрос. Это похоже на обработку заголовка If-None-Match с помощью тега объекта.

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

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

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


адаптер ActiveRecord Ember-Data ожидает 422 UNPROCESSABLE ENTITY для возврата с сервера. Итак, если вы клиент, написано в Ember.js вы должны использовать 422. Только тогда DS.Ошибки будут заполнены возвращенными ошибками. вы можете, конечно, изменить 422 на любой другой код в свой адаптер.