http - состояния - проектирование rest api




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

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

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

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

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


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

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

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

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

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

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


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



Я рекомендую код статуса 422, «Непроцессная организация» .

11.2. 422 Непроцессная организация

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


200

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

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

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

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

Например, если вы вызываете / пользователи / путаете, возвращаете «404 Not found», потому что это может означать:

  • URI ошибочен (HTTP)
  • Пользователи не найдены (REST)

«Запрет / Запрет доступа» может означать:

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

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

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

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

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

  • объект «error» в результате JSON, если что-то пойдет не так
  • Пустой массив / объект JSON, если запись не найдена
  • Параметр bool result / success в сочетании с предыдущими параметрами для лучшей обработки.

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

Wiki из Wiki :

В июле 2004 года британская телекоммуникационная компания BT Group развернула систему блокировки содержимого Cleanfeed, которая возвращает ошибку 404 для любого запроса на контент, который, как потенциально незаконно, используется Internet Watch Foundation. Другие интернет-провайдеры возвращают 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


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

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





http-status-codes