Озверинсто раз обсуждали и еще 1 раз обсудить или вы в самом деле не знаете, что принято возвращать? (на всякий пожарный, поясню, надо возвращать то, что у вас описано в api). Если же брать общую практику, то :
- валидный json, но что-то не так со схемой - 422 анпроцессибл энтити
- просто ожидаем json, а пришел какой-то xml - 400 бэд реквест
- дальше уже вариации на тему

Не в курсе что вы там обсуждали и с кем. 422 - это вообще про webdav, а RFC говорит что нужно 400 (в 2616 было иначе, да):

https://tools.ietf.org/html/rfc7231#section-6.5.1 6.5.1. 400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).



ОзверинАндрей Панфилов- мы запрос можем обработать, но от клиента требуется подтверждение (заголовок или еще что) - а это какой код?

- 403 как бе для таких случаев

403 - это исключительно про права доступа, не нужно ему приписывать что-то другое. Более того, ответ 200 с сервера гарантирует, что пейлоад, идущий с ним, правильного формата и соответствует API, а 4xx может не только приложение выкидывать, а вообще что угодно, так что смысла морочиться с 4xx нет никакого.

Озверин HTTP 403 provides a distinct error case from HTTP 401 ; while HTTP 401 is returned when the client has not authenticated, and implies that a successful response may be returned following valid authentication, HTTP 403 is returned when the client is not permitted access to the resource for some reason besides authentication. This other reason needs to be acted upon before re-requesting access to the resource.вы авторизацию от аутентификации отличаете?

ОзверинHTTP 403 is returned when the client is not permitted access to the resource for some reason besides authenticationНу, это и есть авторизация, а кейс изначально такой: "мы это выполним, но выполнятся оно будет долго, может вызвать рак мозга и пр., продолжить или нет?"

ОзверинТо есть другими словами, вы только что узнали, что сообщество использует 403 в том числе и для того, чтобы указать,что, к примеру, что не хватает какого-то хедера. Может и не использовать, но гитхаб, к примеру - так делает. но они то кто?Я не в курсе что вы там только что узнали (вероятно что в некоторых случаях вместо 403 можно 404 посылать, что само по себе несет некий смысл: 403 подразумевает что ресурс-таки существует, и соответственно раскрывает информацию, впрочем именно это в RFC и написано), однако трактовать фразу "мы запретили доступ по какой-то только нам известной причине" трактовать как "в любой непонятной ситуации слать 403", скажем там, несколько фривольно: существует некоторая общепринятая практика, и здесь 403 - это именно ошибки авторизации, примеры:
- google: https://developers.google.com/analytics/devguides/reporting/core/v3/errors
- amazone: https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html#RESTErrorResponses
- microsoft: https://support.microsoft.com/en-au/help/943891/the-http-status-code-in-iis-7-0-iis-7-5-and-iis-8-0

реализовывать бизнес-логику на 4xx - это все равно что реализовывать бизнес-логику на исключениях.

Озверинвы не можете перевести обычную фразу?Я могу даже больше перевести, но вся суть отражается одним словом: forbidden - запрещено, в приведенном мной сценарии никаких запретов нет - нужно подтвердить действие.

ОзверинТут от авторизации до ratelimit`а ошибки. Что из этого должно следовать? Что 403 используют только для доступ запрещен? Ну да-ну да.
а по вашему ratelimit не относится к тарифному плану и, как следствие, к авторизации?

Озверинк чему это вообще? Есть определенный подход, рест, у него есть определенные варианты использования, есть наработанные практики...причем тут замечание какого-то человека о том, что там можно , а что нет? Уже используются эти исключения в очень большом кол-ве мест, и это не зависит от вашего мнения по этому поводу.
Со стороны инфраструктуры (не приложения), клиент, постоянно генерирующий ошибки, выглядит довольно подозрительно, а с вашим подходом получается примерно так: ну тут пофиг что от кого-то идет постоянный трафик с 403 - это не хакер, это у нас бизнес-логика так реализована.

Озверинp.s. к слову, рейтлимит - это бизнеслогика, потому что на нем завязана оплата.В каком это месте рейтлимит бизнеслогика-то?
- аутентификация: мы тебя знать не знаем, давай свои креденшелы мы тебя проверим
- авторизация: мы тебя знаем, но вот сюда тебе нельзя, потому что мы так решили

т.е. "вы превысили порог количества обращений (в секунду, и пр.) - несите бабки" - это авторизация, прилетает сообщение оно от инфраструктуры , а бизнес-логика сюда натягивается из отдела продаж гугла, а не из моего приложения.