Правильное поведение для общедоступного API-ресурса, запрошенного с использованием маркера авторизации с истекшим сроком действия

Question

Я знаю, что уже есть 401 против 403 вопросов, но это , а не мой случай.

Я спрашиваю: какой сервер в идеаледелать, если запрашиваемый ресурс API общедоступен (не требует требуется авторизация), но запрос включает заголовок авторизации с токеном, который либо неверен, либо срок его действия истек?

Мои рассужденияследующим образом: теоретически сервер может игнорировать его и отвечать, но это выглядит как очень плохая идея.Например, бизнес-логика, лежащая в основе обработки запроса, может отличаться в зависимости от того, аутентифицированы они или нет.Клиентское приложение также должно получать мгновенную обратную связь о том, что оно должно пройти повторную проверку подлинности, и не только, если и когда оно достигает конечной точки, не являющейся общедоступной.

Быть «плохо аутентифицированным» и, следовательно, неявно рассматриваться как анонимный,я думаю, неопределенное и запутанное поведение.

Итак, подведем итог. Оправдано ли использование 400 в этом конкретном случае или есть какая-либо другая, распространенная практика?

Answer 1

Если сам этот API общедоступен, а под общедоступным вы подразумеваете, что не требует никакой аутентификации для пользователя, почему вы вернете пользователю ответ с ошибочным запросом?Подумайте сами, если это имеет смысл, если это общедоступно, вы можете обойти любой вид проверки и сохранить некоторую обработку на сервере.

В связи с этим:

"но это похоже на оченьплохая идея. Например, бизнес-логика, лежащая в основе обработки запроса, может отличаться в зависимости от того, аутентифицирована она или нет. "

Я думаю, что в этом случае вам следует изменить сам API, чтобы потребовать аутентификацию, и не принимать какие-либонеавторизованный пользователь или пользователь с токеном с истекшим сроком действия.

Извините, если я мало чем помог, но это мое мнение по этому поводу.Если он плохо аутентифицирован, то это не публичный API, верно?Публичный API отвечал бы в любом сценарии, мог бы просто иметь некоторые ограничения на запросы в секунду.