Различение кода состояния HTTP 403 и 409 на практике (или 400)

Даже прочитав множество документов, книг, spec я не смог на 100% быть уверенным, следует ли мне использовать код состояния http 403 или 409 в моем случае.

Некоторые утверждают, что код 403 следует использовать только при проблемах с авторизацией, но, видя API Twitter использование 403 для нарушения лимитов обновлений, я думаю, что фактическое использование 403 шире, чем просто проблемы с авторизацией. Возможно, его можно использовать, чтобы сообщить, что запрос нарушил ограничение на стороне сервера.

И, судя по спецификации, 409, кажется, используется, когда мы можем ожидать, что клиент сможет решить проблему.

Я был бы признателен за некоторое разнообразие реальных примеров того, когда использовать 403 и когда использовать 409, а также за мнение о том, какой код использовать в моем случае, который я изложу в аннотации ниже (чтобы не нарушать NDA ).

После редактирования. Пример длинный, но, проще говоря, речь идет о том, какой код следует вернуть в случае сбоя проверки ограничения. Вы всегда возвращаете 400, когда проверка ограничения не удалась? Должен ли я вернуть 400, а не 403 или 409?


Есть клиент, который сообщает сервису А, на какой полке находится конкретная книга. Записывая в БД, какая книга на какой полке, сервис А может сообщить клиенту, что клиент пытается поставить книгу не на ту полку. Служба А может сообщить об этом, обратившись к другой службе Б, у которой есть некоторая логика в определении того, куда следует отправить книгу.

Какой http-код должен использовать сервис A в этом случае?

(Запрос конфликтует с решением службы B — 409? — но клиент не может решить эту проблему, потому что, когда служба B принимает решение, оно является постоянным. И идентификатор книги, и идентификатор книжной полки находятся в параметре пути (т. е. это единственные параметры в этой конечной точке), поэтому клиент не может внести какие-либо изменения, чтобы решить проблему с тем же запросом)

Кроме того, клиент может сообщить службе А, что книжная полка больше не должна использоваться (поскольку она заполнена или по какой-либо другой причине). Когда клиент сообщает службе A, что книжная полка C больше не используется, а позже клиент сообщает службе A, что он хочет поставить другую книгу на книжную полку C, служба A должна сообщить клиенту, что она не может этого сделать. Какой http-код должен использовать сервис A в этом случае? (Запрос будет конфликтовать со статусом базы данных, в котором говорится, что книжная полка C не используется — 409? Но клиент не может решить эту проблему, потому что, когда книжная полка не используется, она постоянно находится в службе A и никогда не используется. опять -- не 409?)

Заранее благодарим вас за ваше время и вклад!


person Clojurevangelist    schedule 12.07.2017    source источник


Ответы (1)


Из двух упомянутых кодов HTTP 403 далеко чаще встречается и описывает допустимый (но неавторизованный) запрос

HTTP 409 не очень распространен. Он описывает конфликт (например, взаимоблокировку или проблему другого типа), который привел к ошибке. Я думаю, что Mozilla дает хороший совет, когда описывает это ошибка чаще всего возникает с глаголом PUT.

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

person Dan Esparza    schedule 12.07.2017
comment
Спасибо за вклад, вы имеете в виду 400, когда сказали 500? - person Clojurevangelist; 12.07.2017
comment
Нет, я имел в виду 500. Код ошибки 500 указывает на общую ошибку приложения или сервера. Код ошибки 400 указывает на неверный запрос — это эквивалентно указанию на то, что один из отправленных параметров был неправильным. - person Dan Esparza; 13.07.2017
comment
Хм, по крайней мере, в моем случае я бы не сказал, что это ошибка на стороне сервера, потому что я думаю, что ошибочный запрос был сделан на стороне клиента. Я хотел знать, используют ли люди 403 даже для проблемы с авторизацией (отсутствует область действия). Или несколько реальных примеров 403 или 409. Но спасибо за усилия! - person Clojurevangelist; 13.07.2017