Каким должен быть код состояния http для ошибки «Служба недоступна в вашем регионе»?

Наш сервис сейчас в 5 городах. Если кто-то пытается вызвать наш сервис API из любого другого города, мы хотим выбросить эту ошибку Service not available in your area.

Вопрос в том, какой код http будет подходящим для этой ошибки?

• сервис 503 недоступен
• 403: запрещено

или что-то другое?

Любой код ошибки HTTP не подходит. Там нет ошибок или проблем любого рода с точки зрения HTTP, поэтому он должен быть что-то в диапазоне 200. Вы вежливо сообщаете некоторым своим пользователям, что они не будут обслуживаться, отправляя обратно документ, который сообщает им об этом. И все это хорошо.

Пользователь не сможет использовать ваше приложение . Это сознательное решение, принятое вашей бизнес-логикой, а не неудача. На уровне HTTP все честно.

редактировать

Похоже, то, на что мы смотрим, это столкновение старой школы с новой. Когда разрабатывался HTTP, не было веб-сервисов, не было ни SOAP, ни JSON, ни REST-принципов. В качестве протокола выше TCP это уже рассматривалось (близко к) уровню приложения, и были определены многие коды состояния высокого уровня. Когда сеть начала использоваться для более богатых, высокоуровневых сервисов и общих средств транспортировки «конвертов», разработчики предпочитали использовать HTTP вместо определения более нового и более чистого протокола только потому, что HTTP был повсеместным.

Таким образом, в контексте современных веб-сервисов HTTP действительно немногим больше, чем тупой транспортный уровень, и большинство его кодов можно считать неприменимыми или устаревшими. Просто выберите один, потому что он приближается к состоянию вашего приложения и находится в этом списке, что когда-то означало, что что-то может показаться безопасным, но я думаю, что это пошло бы неправильно. Вы не хотите, чтобы HTTP играл эту регулирующую роль в контексте веб-службы.

5xxошибки - ошибки сервера - на сервере что-то пошло не так. В частности, 503 указывает, что:

сервер в настоящее время не может обработать запрос из-за временной перегрузки или планового обслуживания

4xxошибки - это ошибки клиента - клиент делает запрос, который сервер не может или не хочет выполнить. В частности, 403 указывает, что

сервер понял запрос, но отказывается его авторизовать. Сервер, который желает обнародовать, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть). [..] Однако запрос может быть запрещен по причинам, не связанным с учетными данными.

Я бы сказал, что 503это явно неправильно, потому что это не временная проблема - вы не поддерживаете запросы в этой области, точка. Можно утверждать, что вы в конечном итоге надеетесь поддержать область, но цель кода - включить заголовок, указывающий, когда клиент может повторить попытку. «Через 6 месяцев» не придерживается намерения.

403 это лучший выбор, потому что ваш сервис просто запрещает запросы из определенных регионов.

Ни один из тех.

Если ваш API хорошо спроектирован, в URL входит название города, например

http://example.com/API/Vienna/HailRide

или же

http://example.com/API/HailRide?city=Vienna

поскольку геолокация IP ненадежна, ваши пользователи могут использовать VPN, ваши пользователи могут захотеть подвезти кого-то еще и т. д. Ответственность за выбор города в зависимости от местоположения пользователя лежит на клиенте API . Обычно клиент имеет гораздо лучшие ресурсы для определения местоположения пользователя в любом случае (например, служба определения местоположения мобильного устройства).

Как только вы это сделаете, правильный ответ

http://example.com/API/SomeUnsupportedCity/HailRide

или же

http://example.com/API/HailRide?city=SomeUnsupportedCity

становится очевидным: 404 Not Found : не существует ресурса для того, чтобы приветствовать поездку в SomeUnsupportedCity.

Это похоже на вопрос круглой дыры / квадратного колышка. Почему ваш единственный ответ должен быть HTTP-кодом? Коды ошибок HTTP не могут охватывать все случаи использования.

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

Если вы этого не сделаете, в следующий раз вы спросите, какой код ошибки HTTP нужно вернуть, когда пользователь запросил внедорожник, но доступен только Prius.

Некоторые имеют смысл.

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

Тем не менее, я бы также выдвинул 451 «Недоступно по юридическим причинам» в качестве возможного статуса возврата в некоторых случаях. Этот статус предполагает, что вы включите (в заголовки) ссылку на соответствующее законодательство. Это специально для случаев, когда клиент не имеет права доступа к вашим ресурсам, и не существует более общего случая, когда клиент находится в неподдерживаемом регионе или области.

Я бы избежал серии статусов 5xx - они часто указывают на технические проблемы на стороне сервера. Это не похоже на случай здесь.

Если ограничение связано с юридическими причинами, то соответствующий код ошибки HTTP - HTTP 451 «Недоступно по юридическим причинам».

Это обычно используется в случае материала, который был отозван из-за действий DMCA или судебных исков из-за кампаний преследования или тому подобного, но дух и буква определения ответа гласят :

В этом документе указывается код состояния протокола передачи гипертекста (HTTP), который используется, когда доступ к ресурсам запрещен вследствие юридических требований.

Сам код является ссылкой на Фаренгейт 451 Рэй Брэдбери.

Люди часто забывают, что коды состояния HTTP являются расширяемыми.

Коды состояния HTTP расширяемы. Приложения HTTP не обязаны понимать значение всех зарегистрированных кодов состояния, хотя такое понимание, очевидно, желательно. Однако приложения ДОЛЖНЫ понимать класс любого кода состояния, как указано первой цифрой, и обрабатывать любой нераспознанный ответ как эквивалентный коду состояния x00 этого класса, за исключением того, что нераспознанный ответ НЕ ДОЛЖЕН кэшироваться. Например, если клиент получил нераспознанный код состояния 431, он может с уверенностью предположить, что с его запросом что-то не так, и обработать ответ, как если бы он получил код состояния 400. В таких случаях пользовательские агенты ДОЛЖНЫ представить пользователю объект, возвращенный с ответом,

https://tools.ietf.org/html/rfc2616#section-6.1.1

Вы всегда можете просто создать свой собственный код состояния в диапазоне 400 для использования вашим API и клиентским приложением.

Сначала я подумал, что 503, потому что описание «служба недоступна», кажется, соответствует проблеме, но, глядя на определения , 503 действительно относится к недоступности сервера. Затем, подумав больше, вы говорите клиенту, что есть проблема с запросом, а не проблема со стороны сервера.

403 ближе, потому что вы говорите пользователю, что получили сообщение и понимаете его, но сервер не желает его удовлетворить. Это может сбивать с толку, поэтому для описания сценария можно добавить текстовое объяснение. Согласно RFC, 404 также является действительной заменой этого кода.

Если кто-то не придумал новый код для этого, 403 или 404 кажутся самыми близкими.

Вам следует сопоставить описание ошибки с кодом, который вы даете:

• если вы говорите, Service not available in your area.вы должны дать, 404потому что вы утверждаете, что услуга недоступна .

• если вы говорите, You are not authorized for this service in your area.вы должны дать, 403потому что вы утверждаете, что звонящий не авторизован .

Я бы пошел на второй.

Существует текущий интернет-проект (срок действия которого истекает 31 декабря 2018 года), в котором предлагаются поправки к статусу HTTP 451, недоступному по юридическим причинам . В проекте предлагается, чтобы ответ 451 содержал geo-scope-blockзаголовок, который должен «соответствовать разделенному запятыми списку кодов стран альфа-2, определенных в [ISO.3166-1]». Однако в проекте также указывается, что код 451 не должен использоваться «оператором для запрета доступа к ресурсу на основе политики, указанной оператором (в отличие от юридического требования, предъявляемого к оператору)».

Таким образом, если у вас нет законного требования на геоблок, то 451 - неправильный код. Какой правильный код тогда? Ну, многие другие ответы уже предложили 403 Запрещено , но все они, похоже, «основаны на мнении», поэтому давайте посмотрим, что делают другие:

• Amazon CloudFront использует 403 Forbidden
• Twitter, по-видимому, возвращает 200 ОК, но объясняет суть содержания JSON - но это для отдельных твитов, а не для всего API
• Pinterest использует 451
• Плагин WordPress IP Geo Block позволяет выбрать любой существующий код

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

Я бы сказал, что нет ничего плохого в том, чтобы просто указать собственный код состояния HTTP, как уже ответил RubberDuck . Пользовательский код состояния в диапазоне 400 может быть даже довольно хорошим вызовом, потому что он определенно привлечет внимание разработчиков, если они увидят что-то вроде «HTTP status 499». «403» слишком легко передать как « ОК, поэтому я неправильно ввел пароль, давайте попробуем что-то другое », и это приводит к потере часов.