Яким має бути код статусу http для помилки "Сервіс недоступний у вашій області"?

51

Наше обслуговування зараз у 5 містах. Якщо хтось намагається зателефонувати на наш сервіс API з будь-якого іншого міста, ми хочемо видалити цю помилку Service not available in your area.

Питання в тому, який відповідний http-код був би для цієї помилки?

503: Служба недоступна
403 Заборонено

чи щось інше?

api api-design http

— Шахаряр
джерело

52

"Якщо хтось намагається зателефонувати на наш сервісний API з будь-якого іншого міста", зауважте, що геолокація IP дуже часто помиляється, якщо ви забороняєте будь-якому користувачеві, чий IP-геолокація перебуває в іншому місті, ви, швидше за все, заблокуєте законних користувачів.

— Пітер Грін

43

Мені не дозволено привітатись за дитиною, яка перебуває в іншому місті і мені потрібно приїхати до аеропорту, щоб відвідати мене?

— Давуд ібн Карім

29

Хоча це не відповідь на питання, HTTP 451 (RFC 7725) може бути корисним майбутнім читачам, які знайдуть це питання. Основна мета - вказати, що вміст недоступний через юридичний запит, дію чи обмеження (авторські права, судовий наказ тощо)

— Tyzoid

34

Якщо з підключенням до мережі, аутентифікацією, внутрішніми помилками в програмі та синтаксично правильним входом нічого поганого не повинно бути повідомлення про помилку. Завдяки "ми не пропонуємо нашу послугу в цій галузі", ви залишили проблеми з технологіями та перейшли до бізнес-питань, тому я не впевнений, що помилка HTTP була б доречною. Я думаю, ви повинні надати відповідне повідомлення на 200 і (або 302 і перенаправити на) про те, що "вибачте, наша служба недоступна у вашому регіоні - поки що. Але ми розширюємо - перевірити ще в кінці 2019 року!" або все, що маркетинговий відділ придумав.

— іваніван

7

З питання не зрозуміло, чи ви хочете заблокувати весь доступ до API на основі розташування клієнтського комп’ютера (гео IP?) Або якщо ви запитуєте код відповіді на конкретний невдалий запит API (наприклад, книга? Address = 123_example_st_london) . Чи місце розташування є частиною вводу, чи ви маєте місце розташування клієнта іншим способом?

— Бен

102

Будь-який код помилки HTTP був би невідповідним. Немає жодних помилок або проблем з точки зору HTTP, тому це має бути щось у діапазоні 200. Ви ввічливо повідомляєте деяких своїх користувачів, що вони не будуть обслуговуватися, надіславши назад документ, який їм це говорить. І це все йде добре.

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

Редагувати

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

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

— Мартін Маат
джерело

56

За цією логікою будь-яка помилка програми повинна повертатися як 200. І всі запити повинні бути POST, навіть видалення. Цей підхід розглядає HTTP як непрозорий транспортний протокол - як TCP. Як правило, так не трактуються API веб-служб - вони намагаються використовувати семантику HTTP на стандартній мові для API. Чому б не повернути 401 для несанкціонованого, а не повернути 200 зі спеціальним нестандартним кодом помилки?

— Авнер Шахар-Каштан

31

За цією логікою жодна програма ніколи не повинна повертати жодної відповіді в діапазоні 400. Це саме та умова, якою є 400 діапазонів відповідей. Також, чи стосується ваше перше речення до всіх майбутніх відповідей, а також до тих, які були розміщені перед вашими?

— Давуд ібн Карім

31

Я мушу погодитися тут, що це просто 200. Користувач задав питання, ми його зрозуміли, ми знаємо правильну відповідь, і ми надали йому відповідь (що трапляється "Ні"). Все добре на землі HTTP.

— Лі Даніел Крокер

8

Хе-хе ... швидкий шлях від "це насправді не помилка" до "так, ти кажеш, ніколи не буває помилкою?"

— svidgen

28

Це. "Ви намагалися отримати доступ до URL-адреси, яка не існує" сильно відрізняється від "Наша компанія не працює у вашому регіоні". Тільки один має щось спільне з HTTP.

— CJ Dennis

87

5xxпомилки - це серверні помилки - на сервері щось пішло не так. Зокрема, 503 вказує, що:

наразі сервер не в змозі обробити запит через тимчасову перевантаження або планове обслуговування

4xxпомилки - це помилки клієнта - клієнт робить запит, який сервер не може або не бажає виконати. Зокрема, 403 вказує на це

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

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

403 є кращим вибором, оскільки ваша послуга просто забороняє запити з певних мов.

— Ерік Штейн
джерело

403 - це випадки, коли доступ заборонений, і клієнт нічого не може з цим зробити. Але в цьому випадку клієнт може (сісти в машину з ноутбуком чи телефоном), тому 403 недоцільно.

— gnasher729

2

@ gnasher729 4xx помилки - це те, що клієнт міг би виправити, що включає 403. Спеціальна специфікація (зокрема) говорить про те, що клієнт може повторно за допомогою різних облікових даних (припустимо, що це були проблеми).

— jaxad0127

22

@ gnasher729 403 не означає, що людина не може нічого з цим зробити. Це означає, що браузер не може нічого з цим робити. Людина завжди може скинути пароль, поговорити з адміністратором або в цьому випадку переїхати в інше місто.

— slebetman

1

@ gnasher729 Клієнт не є користувачем.

— Людина капітана

10

5xx = На жаль, погано, затримайтеся, поки ми вирішимо проблему. 4xx = Просимо вибачення, але, відповідно до політики, ми не можемо задовольнити ваш запит. Ось чому ....

— candied_orange

46

Жоден із них.

Якщо ваш API добре розроблений, URL-адреса містить назву міста, наприклад

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

або

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

оскільки IP геолокація ненадійна, користувачі можуть використовувати віртуальні приватну мережу, користувачі могли б гукнути поїздку для кого - то ще й т.д. Радити місто в залежності від місця розташування користувача є клієнтом API відповідальність «s. Зазвичай клієнт має набагато кращі ресурси для визначення місця розташування користувача у будь-якому випадку (наприклад, послуга локації мобільного пристрою).

Після того, як ви це зробите, правильна відповідь на

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

або

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

стає очевидним: 404 Не знайдено : Не існує ресурсу для того, щоб їхати на їзді в SomeUnsupportedCity.

— Хайнці
джерело

6

Це має бути прийнятою відповіддю: дизайн API - це не лише відповідність старим числовим кодам, а сценарій щодо vpn тощо є цілком реалістичним.

— Едоардо

10

Я з цим не погоджуюся. Включення назви міста в URL-адресу може спричинити за собою всілякі проблеми в дорозі, оскільки це змушує клієнта визначати назву міста на основі місця розташування, а результат вам може не сподобатися. Наприклад, ви в Лос-Анджелесі чи Беверлі-Хіллз? Лондон чи Вестмінстер? Що станеться, якщо клієнт вважає, що він знаходиться в Річардсоні, але ви хочете, щоб API обслуговував всю область Далласа? Для клієнта було б кращою ідеєю просто поставити місця збору / перевантаження; сервер може визначити, чи є вони в зоні обслуговування, і відповісти відповідним чином.

— Зак Ліптон

11

@ZachLipton Я впевнений, що назви міст були лише прикладом, залежно від власних правил роботи ОП, як вони визначають "місто" чи "місцеположення". Це також може бути координатою.

— Бергі

1

@ZachLipton ні, справа тут не в тому, щоб користувач не використовував IP-адресу клієнта, щоб зрозуміти місцеположення, це просто неправильно

— Edoardo

3

@eddyce Я згоден, що використання IP-адреси клієнта є поганою ідеєю з багатьох причин. Я кажу, що / API / Vienna / HailRide також схильний до проблем, тому що він вимагає від клієнта перетворення місць у назви міст, і це не відображення 1 на 1, яке відповідає областям, якими займається компанія.

— Зак Ліптон

26

Це здається питанням із круглим отвором / квадратним кілочком. Чому для вашого єдиного відповіді повинен бути HTTP-код? Коди помилок HTTP не можуть охопити всі випадки використання.

Усі ваші дзвінки API повинні мати додаткові повідомлення, що повертаються, тобто невелике повідомлення про помилку JSON. Дайте їм номер 403 (бо, дійсно, вони не мають дозволу на використання API з урахуванням місцезнаходження) і поверніть додатковий біт інформації, як ви пропонуєте.

Якщо цього не зробити, то наступного разу ви запитаєте, який код помилки HTTP повернути, коли користувач попросив позашляховик, але доступний лише Prius.

— stdunbar
джерело

5

+1 за ваше останнє речення. Підсумовує це красиво.

— LoztInSpace

1

Добре, що цілком очевидно потребуватиме 3xx переспрямування. ;)

— Брендон Мінтерн

Останній випадок, ймовірно, вимагає певної відповіді 4xx: користувач зробив запит, який сервер не може виконати. Було б 400, якби вибір був недійсним входом, або 404, якщо саме місце розташування просто не існує. Хоча це може бути і 200, якщо це критерії пошуку і просто немає відповідностей.

— jpmc26

11

Кілька мають сенс.

403 Заборонено з причин, про які Ерік Штейн згадує у своїй відповіді . Ви можете використовувати різноманітну інформацію, надану запитом, щоб визначити, де знаходиться клієнт і хто такий клієнт, і, виходячи з цього запиту, сервер не може або не бажає відповісти.

Однак я також висловив би 451 Недоступні з юридичних причин як можливий статус повернення в деяких випадках. Цей статус очікує, що ви включите (у заголовки) посилання на відповідне законодавство. Це спеціально для тих випадків, коли клієнт не має права доступу до ваших ресурсів, і не існує більш загального випадку клієнта в непідтримуваному регіоні чи районі.

Я б уникнув серії 5xx статусів - вони часто вказують на технічні проблеми на стороні сервера. Тут, мабуть, не так.

— Томас Оуенс
джерело

Можливо, причина в цьому випадку полягає в тому, що немає сенсу розповідати користувачеві про автомобілі, які перебувають у їхньому місті. Тож це не так у 451

— max630

4

@ max630 Ви не можете цього припустити з питання. 403 Заборонений, швидше за все, правильний вибір. Однак, якщо існують юридичні обмеження щодо послуги, натомість можна використовувати більш конкретні 451. 451 часто розглядається як більш конкретна версія 403 для особливо конкретних випадків використання, тому є сенс піднести це.

— Томас Оуенс

8

@ max630 - цілком можливо, що тут підходить 451. Багато юрисдикцій вимагають, щоб оператори такого типу послуг були зареєстровані в регіональних органах влади перед наданням послуги. Насправді їм може бути юридично заборонено обробляти певні запити, якщо вони походять поза межами області.

— Жуль

5

Якщо обмеження пов'язане з юридичними причинами, то відповідним кодом помилки HTTP є HTTP 451, "Недоступно через юридичні причини".

Зазвичай це застосовується у випадку матеріалів, які були відкликані через дії DMCA або судові позови через кампанії зловживань тощо, але дух і буква визначення відповіді вказує:

Цей документ визначає код статусу протоколу передачі гіпертексту (HTTP) для використання, коли доступ до ресурсів заборонено внаслідок юридичних вимог.

Сам код - це посилання на Фаренгейта 451 Рея Бредбері.

— пухнастий
джерело

3

Люди часто забувають, що коди статусу HTTP розширюються.

Коди статусу HTTP розширюються. HTTP-додатки не повинні розуміти значення всіх зареєстрованих кодів статусу, хоча таке розуміння, очевидно, бажано. Однак додатки ОБОВ'ЯЗКОВО розуміють клас будь-якого коду статусу, як зазначено у першій цифрі, і розглядають будь-яку нерозпізнану відповідь як еквівалентну коду статусу x00 цього класу, за винятком того, що нерозпізнаний відповідь НЕ МОЖЕ бути кешований. Наприклад, якщо клієнт отримав нерозпізнаний код статусу 431, він може сміливо припускати, що в його запиті сталося щось не так, і ставитись до відповіді так, ніби отримав код 400 стану. У таких випадках, користувацькі агенти ДОЛЖНІ представити користувачеві сутність, яку повернув із відповіддю

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

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

— Гумова качка
джерело

Хм ... може не знадобиться, якщо запит містив Expect token;city="Albequerque"заголовок. Тоді найбільш прийнятною відповідь буде 417, очікування не вдалося. tools.ietf.org/html/rfc2616#section-10.4.18 Припустимо, звичайно, що це для веб-сервісу.

— Берін Лорич

Можливо, не потрібно @BerinLoritsch, але замість того, щоб намагатися примусити вписати ситуацію в існуючий код, може бути краще просто пограбувати і скористатися користувацьким.

— RubberDuck

0

Спочатку я подумав, що 503 тому, що опис "послуга недоступна", схоже, узгоджується з проблемою, але, дивлячись на визначення , 503 дійсно характерний для недоступності сервера. Потім більше роздумуючи, ви говорите клієнтові, що є проблема із запитом, а не що з серверною проблемою.

403 ближче, тому що ви повідомляєте користувачеві, що отримали повідомлення, і розумієте його, але сервер не бажає його задовольняти. Це може заплутати, тому для опису сценарію можна додати текстове пояснення. Згідно RFC, 404 також є дійсною заміною цього коду.

Якщо хтось не придумав новий код для цього, 403 або 404 здаються найближчими.

— JimmyJames
джерело

Однозначно не код 5xx, тому що це означає, що спробувати той самий запит пізніше може вдатися. Код 4xx безумовно спонукає клієнта не намагатися повторити, не змінюючи хоча б частину запиту (у цьому випадку поле "Місце розташування служби").

— Toby Speight

0

Ви повинні відповідати опису помилки з кодом, який ви даєте:

якщо ви скажете, Service not available in your area.тоді вам слід дати це, 404оскільки ви стверджуєте, що послуга недоступна .
якщо ви скажете, You are not authorized for this service in your area.тоді ви повинні дати те, 403що ви заявляєте, що абонент не має права .

Я б пішов на другу.

— Едоардо
джерело

6

404 - це не про доступність , це про існування . Просто тому, що служба не доступна за певних обставин, ви не повинні надати відповідь 404, якщо ви не хочете, щоб люди вірили, що її взагалі не існує. Відповідь 404 була б безглуздою для цієї ситуації.

— Жуль

@jules Відповідно до специфікації для 403 (яка може бути застарілою): "Якщо сервер не бажає надавати цю інформацію клієнту, замість цього може використовуватися код статусу 404 (Не знайдено). " Отже, якщо з 403 буде нормально, то 404 також буде, але не обов'язково з вказаної причини.

— JimmyJames

@JimmyJames - так, це в специфікації, але це дуже погана ідея, оскільки це робить проблеми налагодження вкрай важкими. Не те, що потрібно в API.

— Jules

3

@Jules Сервіс не існує в деяких районах. Так само, як є багато невеликих магазинів, які існують лише в моєму місті, тому запитати їх адресу в іншому місті правильної відповіді є "не існує".

— Енді

ехм, якщо говорити про "існування" про службовий шлях до найменшого - філософського, задля ясності, коли ви публікуєте шлях, ви повинні надати відповідь, 403 - це спосіб пройти в цьому випадку, з деяким словесним описом ситуація.

— Едоардо

0

Існує поточний Інтернет-проект (термін дії якого закінчується 31 грудня 2018 року), який пропонує зміни до статусу HTTP 451, недоступного для юридичних причин . У проекті передбачається, що відповідь 451 повинна містити geo-scope-blockзаголовок, який повинен "відповідати розділеному комами списку кодів країн альфа-2, визначених у [ISO.3166-1]". Однак у проекті також визначено, що код 451 не повинен використовуватися "оператором для відмови у доступі до ресурсу на основі політики, визначеної оператором (на відміну від правової вимоги, що ставиться до оператора)".

Отже, якщо припустити, що ви не маєте законних вимог щодо geoblock, 451 - це не правильний код. Який тоді правильний код? Ну, численні інші відповіді вже пропонують 403 Заборонено , але всі вони, здається, "засновані на думці", тож давайте подивимося, що роблять інші:

Amazon CloudFront використовує 403 Заборонено
Twitter, мабуть, повертає 200 ОК, але пояснює питання у вмісті JSON - але це стосується окремих твітів, а не всього API
Pinterest використовує 451
Плагін WordPress IP Geo Block дозволяє вибрати будь-який існуючий код

Отже, немає жодного універсального рішення, вам просто доведеться вибрати таке, яке, на вашу думку, найкраще підходить для вашої ситуації. Але що б ви не вибрали, обов'язково поясніть актуальну проблему органу відповідей .

Я б сказав, що не було б нічого поганого в тому, щоб просто вказати спеціальний код статусу HTTP, як RubberDuck вже відповів . Спеціальний код статусу в діапазоні 400 насправді може бути навіть дуже хорошим дзвінком, оскільки це, безумовно, приверне увагу розробників, якщо вони побачать щось на кшталт "HTTP status 499". "403" занадто просто передати " ОК, щоб я помилився з паролем, давайте спробуємо щось інше ", і це призводить до втрати часу.

— ZeroOne
джерело