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

Question

Даже после прочтения многих документов, книг, спецификаций [ https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html] я не мог на 100 процентов быть уверенным, должен ли я использовать http-код состояния 403 или 409 в моем дело.

Есть мнения, что 403 следует использовать только с проблемой авторизации, но, видя (твиттер api) [ https://dev.twitter.com/overview/api/response-codes] используя 403 для нарушения пределов обновления, я думаю, что 403 используется шире, чем просто вопросы авторизации. Может быть, это можно использовать, чтобы сообщить о нарушении запроса на стороне сервера.

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

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

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

================================================== ==================

Есть клиент, который сообщает службе А, на какой полке будет храниться книга. Во время записи в БД того, какая книга находится на какой полке, служба А может сказать клиенту, что пытается поместить книгу не на ту полку. Служба A может сказать об этом, запросив другую службу B, которая в основном имеет некоторую логику при принятии решения, куда следует обратиться в книгу. Какой http-код должен использовать сервис A в этом случае? (запрос конфликтует с решением 409 службы B? но клиент не может решить эту проблему, потому что, когда служба B принимает решение, оно является постоянным. И идентификатор книги, и идентификатор книжной полки находятся в параметре пути (они являются единственными параметрами в этой конечной точке) поэтому клиент не может внести какие-либо изменения, чтобы решить проблему с тем же запросом)

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

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

Answer 1

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

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

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