Jaki powinien być kod stanu HTTP dla błędu „Usługa niedostępna w Twoim regionie”?

51

Nasz serwis jest obecnie w 5 miastach. Jeśli ktoś spróbuje wywołać interfejs API naszej usługi z dowolnego innego miasta, chcemy zgłosić ten błąd Service not available in your area.

Pytanie brzmi: jaki byłby odpowiedni kod http dla tego błędu?

  • 503 Usługa niedostępna
  • 403: zabronione

albo coś innego?

api api-design http Shaharyar
źródło
52
„Jeśli ktoś spróbuje zadzwonić do interfejsu API naszej usługi z dowolnego innego miasta”, zauważ, że geolokalizacja IP jest bardzo często błędna, jeśli zabronisz użytkownikom, których geolokalizacja IP do innego miasta, najprawdopodobniej zablokujesz legalnych użytkowników.
Peter Green,
43
Czy nie wolno mi przywołać przejażdżki dla mojego dziecka, które jest w innym mieście i musi przyjechać na lotnisko, aby mnie odwiedzić?
Dawood ibn Kareem,
29
Chociaż nie jest to odpowiedź na pytanie, HTTP 451 (RFC 7725) może być przydatny dla przyszłych czytelników, którzy znajdą to pytanie. Jego głównym celem jest wskazanie, że treść jest niedostępna z powodu wniosku prawnego, działania lub ograniczenia (prawa autorskie, orzeczenie sądowe itp.)
Tyzoid
34
Jeśli nie ma nic złego w łączności sieciowej, uwierzytelnianiu, bez błędów wewnętrznych w aplikacji i poprawnych pod względem składniowym danych wejściowych, komunikat o błędzie nie powinien być wyświetlany. Dzięki „nie oferujemy naszych usług w tym obszarze” porzuciłeś problemy techniczne i zająłeś się problemami biznesowymi, więc nie jestem pewien, czy błąd HTTP byłby odpowiedni. Myślę, że powinieneś podać 200 i (lub 302 i przekierować do) odpowiednią wiadomość o „przepraszam, że nasza usługa nie jest jeszcze dostępna w Twojej okolicy - ale rozwijamy się - sprawdź pod koniec 2019 roku!” lub cokolwiek wymyśli dział marketingu.
ivanivan
7
Nie jest jasne, czy chcesz zablokować cały dostęp do interfejsu API na podstawie lokalizacji komputera klienckiego (geo IP?), Czy pytasz o kod odpowiedzi dla konkretnego nieudanego żądania interfejsu API (np. Adres książki = 123_przykład_st_ Londyn) . Czy lokalizacja jest częścią danych wejściowych, czy też masz lokalizację klienta w inny sposób?
Ben

Odpowiedzi:

102

Każdy kod błędu HTTP byłby nieodpowiedni. Z punktu widzenia HTTP nie ma żadnych błędów ani problemów, więc powinno to być coś z zakresu 200. Grzecznie informujesz niektórych użytkowników, że nie będą oni obsługiwani, wysyłając z powrotem dokument, który im to mówi. I wszystko idzie dobrze.

Użytkownik nie będzie mógł korzystać z Twojej aplikacji . To świadoma decyzja podejmowana przez logikę biznesową, a nie nieszczęście. Na poziomie HTTP wszystko jest uczciwe.

Edytować

Wygląda na to, że patrzymy tutaj na starcie starej szkoły z nową szkołą. Gdy zaprojektowano HTTP, nie było usług internetowych, nie było SOAP, JSON ani zasad REST. Jako protokół powyżej TCP był to już rozważany (zbliżony do) poziom aplikacji i zdefiniowano wiele kodów statusu wysokiego poziomu. Kiedy sieć zaczęła być wykorzystywana do bogatszych, usług wysokiego poziomu i wspólnych środków transportu „kopert”, projektanci podchwycili HTTP zamiast definiować nowszy i czystszy protokół, tylko dlatego, że HTTP był wszechobecny.

Tak więc w kontekście nowoczesnych usług internetowych HTTP jest w rzeczywistości niewiele więcej niż głupią warstwą transportową, a większość jego kodów można uznać za nieobowiązujące lub przestarzałe. Po prostu wybranie jednego, ponieważ zbliża się do stanu Twojej aplikacji i zdarza się, że znajduje się na tej liście, co kiedyś oznaczało, że coś może wydawać się nieszkodliwe, ale myślę, że wysłałoby to niewłaściwy komunikat. Nie chcesz, aby HTTP pełnił tę regulującą rolę w kontekście usług sieciowych.

Martin Maat
źródło
56
Zgodnie z tą logiką każdy błąd aplikacji powinien zostać zwrócony jako 200. A wszystkie żądania powinny być POST, nawet usunięte. Takie podejście traktuje HTTP jako nieprzejrzysty protokół transportowy - podobnie jak TCP. Nie tak zwykle traktuje się interfejsy API usług sieciowych - starają się wykorzystywać semantykę HTTP jako standardowy język interfejsów API. Dlaczego nie zwrócić 401 za nieautoryzowane, zamiast zwracać 200 z niestandardowym, niestandardowym kodem błędu?
Avner Shahar-Kashtan
31
Zgodnie z tą logiką żadna aplikacja nigdy nie powinna zwracać odpowiedzi w zakresie 400. Jest to dokładnie ten warunek, dla którego przeznaczony jest zakres 400 odpowiedzi. Czy twoje pierwsze zdanie dotyczy wszystkich przyszłych odpowiedzi, a także tych, które zostały zamieszczone przed tobą?
Dawood ibn Kareem,
31
Muszę się tutaj zgodzić, że jest to zwykły numer 200. Użytkownik zadał pytanie, zrozumieliśmy go, znamy prawidłową odpowiedź i podaliśmy mu odpowiedź (która okazuje się „nie”). Wszystko dobrze w krainie HTTP.
Lee Daniel Crocker,
8
Hej ... szybka podróż od „to nie jest tak naprawdę błąd” do „więc, mówisz, że nic nigdy nie jest błędem?”
svidgen
28
To. „Próbowano uzyskać dostęp do adresu URL, który nie istnieje” różni się bardzo od „Nasza firma nie działa w Twojej okolicy”. Tylko jeden ma coś wspólnego z HTTP.
CJ Dennis
87

5xxbłędy to błędy serwera - coś poszło nie tak na serwerze. W szczególności 503 wskazuje, że:

serwer obecnie nie jest w stanie obsłużyć żądania z powodu tymczasowego przeciążenia lub zaplanowanej konserwacji

4xxbłędy są błędami klienta - klient wysyła żądanie, którego serwer nie jest w stanie lub nie chce spełnić. W szczególności wskazuje to 403

serwer zrozumiał żądanie, ale odmawia jego autoryzacji. Serwer, który chce podać do publicznej wiadomości, dlaczego żądanie zostało zabronione, może opisać ten powód w ładunku odpowiedzi (jeśli taki istnieje). [..] Jednak żądanie może być zabronione z powodów niezwiązanych z poświadczeniami.

Twierdziłbym, że 503jest to wyraźnie niepoprawne, ponieważ nie jest to tymczasowy problem - nie obsługujesz wniosków w tym obszarze, kropka. Można argumentować, że ostatecznie masz nadzieję na obsługę tego obszaru, ale celem kodu jest dołączenie nagłówka wskazującego, kiedy klient może spróbować ponownie. „Za 6 miesięcy” nie spełnia tego założenia.

403 jest lepszym wyborem, ponieważ Twoja usługa po prostu zabrania żądań z niektórych lokalizacji.

Eric Stein
źródło
403 dotyczy przypadków, w których dostęp jest zabroniony, a klient nie może nic z tym zrobić. Ale w tym przypadku klient może (wsiąść do samochodu z laptopem lub telefonem), więc 403 jest nieodpowiedni.
gnasher729,
2
@ gnasher729 Błędy 4xx dotyczą rzeczy, które klient może naprawić, w tym 403. (Połączona) specyfikacja wyraźnie stwierdza, że ​​klient może ponowić próbę przy użyciu różnych poświadczeń (zakładając, że poświadczenia były problemem).
jaxad0127
22
@ gnasher729 403 nie oznacza, że ​​człowiek nie może nic z tym zrobić. Oznacza to, że przeglądarka nic na to nie poradzi. Człowiek zawsze może zresetować hasło, porozmawiać z administratorem lub w tym przypadku przenieść się do innego miasta.
slebetman
1
@ gnasher729 Klient nie jest użytkownikiem.
Captain Man
10
5xx = Ups nasze złe, poczekaj, aż naprawimy problem. 4xx = Przepraszamy, ale obecnie nie możemy spełnić Twojego żądania. Oto dlaczego ....
candied_orange
46

Żaden z nich.

Jeśli interfejs API jest dobrze zaprojektowany, adres URL zawiera nazwę miasta, np

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

lub

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

ponieważ geolokalizacja IP jest niewiarygodna, Twoi użytkownicy mogą korzystać z VPN, Twoi użytkownicy mogą chcieć wezwać kogoś innego, itp. Sugerowanie miasta na podstawie lokalizacji użytkownika jest obowiązkiem klienta API . Zwykle klient ma i tak znacznie lepsze zasoby do określania lokalizacji użytkownika (na przykład usługa lokalizacji urządzenia mobilnego).

Gdy to zrobisz, poprawna odpowiedź na 

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

lub

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

staje się oczywiste: 404 nie znaleziono : Nie istnieje żaden zasób na wezwanie do przejażdżki w SomeUnsupportedCity.

Heinzi
źródło
6
To powinna być zaakceptowana odpowiedź: projektowanie interfejsu API nie polega tylko na zgodności ze starymi kodami numerycznymi, a scenariusz dotyczący sieci VPN itp. Jest dość realistyczny.
Edoardo,
10
Muszę się z tym nie zgodzić. Umieszczenie nazwy miasta w adresie URL może prowadzić do różnego rodzaju problemów na drodze, ponieważ zmusza klienta do określenia nazwy miasta na podstawie lokalizacji, a wynik może Ci się nie podobać. Na przykład, jesteś w Los Angeles lub Beverly Hills? Londyn czy Westminster? Co się stanie, jeśli klient myśli, że jest w Richardson, ale chcesz, aby interfejs API obsługiwał cały obszar Dallas? Byłoby lepszym pomysłem dla klienta, aby po prostu podać miejsca odbioru / odbioru; serwer może ustalić, czy znajduje się w obszarze usługi i odpowiednio zareagować.
Zach Lipton
11
@ZachLipton Jestem pewien, że nazwy miast były tylko przykładem, to zależy od rzeczywistych reguł biznesowych PO, w jaki sposób definiują „miasto” lub „lokalizację”. Równie dobrze mogłaby to być współrzędna.
Bergi,
1
@ZachLipton nie, chodzi o to, że usługa nie używa adresu IP klienta do zrozumienia lokalizacji, to po prostu źle
Edoardo
3
@eddyce Zgadzam się, że korzystanie z adresu IP klienta jest złym pomysłem z wielu powodów. Mówię, że / API / Vienna / HailRide jest również podatny na problemy, ponieważ wymaga od klienta konwersji lokalizacji na nazwy miast, a to nie jest mapowanie 1-do-1, które odpowiada obszarom, w których firma prowadzi działalność.
Zach Lipton
26

To wydaje się pytaniem o okrągłym otworze / kołku. Dlaczego jedyną odpowiedzią jest kod HTTP? Kody błędów HTTP nie mogą obejmować wszystkich przypadków użycia.

Wszystkie twoje wywołania API powinny mieć dodatkowe komunikaty, które powracają - tj. Mały komunikat o błędzie JSON. Daj im 403 (bo naprawdę nie mają pozwolenia na używanie interfejsu API ze względu na lokalizację) i zwróć dodatkowy kawałek informacji, jak sugerujesz.

Jeśli tego nie zrobisz, następnym razem zapytasz, jaki kod błędu HTTP należy zwrócić, gdy użytkownik poprosił o SUV, ale dostępny jest tylko Prius.

stdunbar
źródło
5
+1 za ostatnie zdanie. Ładnie podsumowuje.
LoztInSpace
1
Cóż, to całkiem wyraźnie musiałoby być przekierowaniem 3xx. ;)
Brandon Mintern
Ostatni przypadek prawdopodobnie uzasadnia odpowiedź 4xx: użytkownik wysłał żądanie, którego serwer nie może spełnić. Byłoby to 400, gdyby wybór był jakimś błędnym wejściem lub 404, gdyby sama lokalizacja po prostu nie istniała. Chociaż może to być 200, jeśli jest to kryterium wyszukiwania i po prostu nie ma żadnych dopasowań.
jpmc26,
11

Kilka ma sens.

403 Zabronione, z powodów, o których wspomina Eric Stein w swojej odpowiedzi . Możesz użyć różnych informacji podanych w żądaniu, aby ustalić, gdzie jest klient i kim jest klient, i na podstawie tego żądania serwer nie może lub nie chce odpowiedzieć.

Podałbym jednak również 451 Niedostępny z powodów prawnych jako możliwy status zwrotu w niektórych przypadkach. Ten status wymaga włączenia (w nagłówkach) linku do odpowiednich przepisów. Dotyczy to w szczególności przypadków, w których klient nie ma dostępu do zasobów, a nie ma bardziej ogólnego przypadku klienta w nieobsługiwanym regionie lub obszarze.

Unikałbym serii statusów 5xx - często wskazują one na problemy techniczne po stronie serwera. Wydaje się, że tak nie jest.

Thomas Owens
źródło
Prawdopodobnie powodem jest to, że nie ma sensu informować użytkowników o samochodach, które nie znajdują się w ich mieście. Tak nie jest w przypadku 451
max630
4
@ max630 Nie można zakładać, że z pytania. 403 Zabroniony jest najprawdopodobniej właściwym wyborem. Jeśli jednak istnieją ograniczenia prawne dotyczące usługi, można zamiast tego użyć bardziej szczegółowego 451. 451 jest często postrzegana jako bardziej szczegółowa wersja 403 dla bardzo szczególnych przypadków użycia, więc warto go przywołać.
Thomas Owens
8
@ max630 - jest całkiem możliwe, że 451 jest tutaj odpowiednie. Wiele jurysdykcji wymaga, aby operatorzy tego rodzaju usługi byli zarejestrowani w organach regionalnych przed świadczeniem usługi. Mogą oni być prawnie zabronieni w przetwarzaniu niektórych wniosków, jeśli pochodzą one poza obszar.
Jules
5

Jeśli ograniczenie wynika z przyczyn prawnych, wówczas odpowiedni kod błędu HTTP to HTTP 451 „Niedostępny z powodów prawnych”.

Jest to zwykle stosowane w przypadku materiałów, które zostały odwołane z powodu działań DMCA lub procesów sądowych z powodu kampanii nękających itp., Ale duch i litera definicji odpowiedzi brzmią :

Ten dokument określa kod statusu protokołu przesyłania hipertekstu (HTTP) do użycia w przypadku odmowy dostępu do zasobów w wyniku wymagań prawnych.

Sam kod jest odniesieniem do Fahrenheita 451 autorstwa Ray Bradbury.

puszysty
źródło
3

Ludzie często zapominają, że kody stanu HTTP są rozszerzalne.

Kody stanu HTTP są rozszerzalne. Aplikacje HTTP nie są wymagane do zrozumienia znaczenia wszystkich zarejestrowanych kodów stanu, chociaż takie zrozumienie jest oczywiście pożądane. Jednak aplikacje MUSZĄ zrozumieć klasę dowolnego kodu statusu, jak wskazano przez pierwszą cyfrę, i traktować każdą nierozpoznaną odpowiedź jako równoważną kodowi stanu x00 tej klasy, z wyjątkiem tego, że nierozpoznana odpowiedź NIE MOŻE być buforowana. Na przykład, jeśli klient otrzyma nierozpoznany kod statusu 431, może bezpiecznie założyć, że coś było nie tak z jego żądaniem i potraktować odpowiedź tak, jakby otrzymał kod statusu 400. W takich przypadkach agenty użytkownika MUSZĄ przedstawić użytkownikowi, który podmiot zwrócił z odpowiedzią,

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

Zawsze możesz po prostu stworzyć swój własny kod statusu z zakresu 400 do użytku przez interfejs API i aplikację kliencką.

Gumowa kaczuszka
źródło
Hmm ... może nie być konieczne, jeśli żądanie zawiera Expect token;city="Albequerque"nagłówek. Wtedy najbardziej odpowiednią odpowiedzią byłoby 417, oczekiwanie nie powiodło się. tools.ietf.org/html/rfc2616#section-10.4.18 Zakładając oczywiście, że jest to usługa internetowa.
Berin Loritsch
Może nie jest to konieczne @BerinLoritsch, ale zamiast próbować na siłę dopasować do sytuacji, do istniejącego kodu, to może być lepiej po prostu punt i użyć niestandardowego jeden.
RubberDuck
0

Na początku myślałem, że 503, ponieważ opis „usługa niedostępna” wydaje się być zgodny z problemem, ale patrząc na definicje , 503 jest naprawdę specyficzne dla niedostępności serwera. Następnie myśląc więcej, mówisz klientowi, że istnieje problem z żądaniem, a nie, że występuje problem po stronie serwera.

403 jest bliżej, ponieważ mówisz użytkownikowi, że otrzymałeś wiadomość i rozumiesz ją, ale serwer nie chce jej spełnić. Może to być mylące, dlatego można dodać objaśnienie tekstowe opisujące scenariusz. Zgodnie z RFC 404 jest również ważnym substytutem tego kodu.

O ile ktoś nie wymyślił nowego kodu do tego, 403 lub 404 wydają się być najbliższe.

JimmyJames
źródło
Zdecydowanie nie jest to kod 5xx, ponieważ oznacza to, że próba wykonania tego samego żądania później może się powieść. Kod 4xx zdecydowanie informuje klienta, aby nie próbował ponownie bez zmiany przynajmniej części żądania (w tym przypadku pola „lokalizacja usługi”).
Toby Speight,
0

Powinieneś dopasować opis błędu do kodu, który podajesz:

  • jeśli to powiesz Service not available in your area., powinieneś dać, 404ponieważ twierdzisz, że usługa nie jest dostępna .

  • jeśli to powiesz You are not authorized for this service in your area., powinieneś dać, 403ponieważ twierdzisz, że dzwoniący nie jest autoryzowany .

Poszedłbym na drugi.

Edoardo
źródło
6
404 nie dotyczy dostępności , chodzi o istnienie . Tylko dlatego, że usługa nie jest dostępna w niektórych okolicznościach, nie powinieneś udzielać odpowiedzi 404, chyba że chcesz, aby ludzie wierzyli, że ona w ogóle nie istnieje. Odpowiedź 404 byłaby w tej sytuacji bez znaczenia.
Jules
@jules Zgodnie ze specyfikacją dla 403 (która może być nieaktualna): „Jeśli serwer nie chce udostępnić tej informacji klientowi, zamiast tego można użyć kodu stanu 404 (Nie znaleziono) ”. Więc jeśli 403 jest w porządku, to 404 również byłoby, ale niekoniecznie z podanego powodu.
JimmyJames,
@JimmyJames - tak, jest zgodny ze specyfikacją, ale jest to naprawdę zły pomysł, ponieważ bardzo utrudnia debugowanie problemów. Nie to, czego chcesz w interfejsie API.
Jules
3
@Jules Usługa nie istnieje w niektórych obszarach. Podobnie jak wiele małych sklepów, które istnieją tylko w moim mieście, więc pytając o ich adres w innym mieście, prawidłowa odpowiedź brzmi „nie istnieje”.
Andy,
ehmm mówienie o „istnieniu” o ścieżce adresu URL usługi jest najmniej - filozoficzne, dla jasności, kiedy opublikujesz ścieżkę, musisz podać odpowiedź, 403 jest właściwą drogą w tym przypadku, z pewnym słownym opisem sytuacja.
Edoardo,
0

Dostępny jest obecnie Internet-Draft (który wygasa 31 grudnia 2018 r.), Który proponuje poprawki do HTTP 451 Niedostępne z powodów prawnych . Projekt sugeruje, że odpowiedź 451 powinna zawierać geo-scope-blocknagłówek, który powinien „odpowiadać rozdzielonej przecinkami liście kodów krajów alfa-2 zdefiniowanych w [ISO.3166-1]”. Jednak projekt określa również, że kod 451 nie powinien być używany „przez operatora, aby odmówić dostępu do zasobu na podstawie polityki określonej przez operatora (w przeciwieństwie do żądania prawnego złożonego operatorowi”).

Zakładając, że nie masz legalnego zapotrzebowania na geoblok, 451 nie jest prawidłowym kodem. Jaki jest zatem poprawny kod? Cóż, wiele innych odpowiedzi sugerowało już 403 Zabronione , ale wszystkie wydają się być oparte na opiniach, więc zobaczmy, co robią inni:

Tak więc nie ma jednego uniwersalnego rozwiązania, wystarczy wybrać takie, które najlepiej pasuje do Twojej sytuacji. Ale cokolwiek wybierzesz, wyjaśnij rzeczywisty problem w treści odpowiedzi .

Powiedziałbym, że nie byłoby nic złego w określeniu niestandardowego kodu stanu HTTP, na przykład Rubberduck już odpowiedział . Niestandardowy kod stanu z zakresu 400 może nawet być całkiem dobrym wywołaniem, ponieważ na pewno zwróci uwagę programistów, jeśli zobaczą coś w rodzaju „HTTP status 499”. „403” jest zbyt łatwe do przekazania jako „ OK, więc pomyliłem hasło, spróbujmy czegoś innego ”, a to prowadzi do zmarnowanych godzin.

Zero jeden
źródło