Wie lautet der http-Statuscode für den Fehler "Dienst in Ihrer Region nicht verfügbar"?

51

Unser Service ist derzeit in 5 Städten verfügbar. Wenn jemand versucht, unsere Service-API aus einer anderen Stadt aufzurufen, möchten wir diesen Fehler auslösen Service not available in your area.

Die Frage ist, was ist der passende http-Code für diesen Fehler?

  • 503 Dienst nicht verfügbar
  • 403 Verboten

oder etwas anderes?

api  api-design  http 
— Shaharyar
quelle
52
"Wenn jemand versucht, unsere Service-API von einer anderen Stadt aus aufzurufen" Beachten Sie, dass die IP-Geolokalisierung sehr häufig falsch ist. Wenn Sie Benutzern verbieten, deren IP-Geolokalisierung in eine andere Stadt erfolgt, werden Sie höchstwahrscheinlich legitime Benutzer aussperren.
— Peter Green
43
Darf ich meinem Kind, das sich in einer anderen Stadt befindet und zum Flughafen kommen muss, um mich zu besuchen, keine Fahrt anbieten?
— Dawood ibn Kareem
29
HTTP 451 (RFC 7725) ist zwar keine Antwort auf die Frage, kann aber für zukünftige Leser hilfreich sein, die diese Frage finden. Der Hauptzweck besteht darin, anzuzeigen, dass der Inhalt aufgrund einer rechtlichen Aufforderung, eines Verfahrens oder einer Einschränkung (Urheberrecht, Gerichtsbeschluss usw.) nicht verfügbar ist
— Tyzoid
34
Wenn an der Netzwerkkonnektivität, der Authentifizierung, den anwendungsinternen Fehlern und der syntaktisch gültigen Eingabe nichts auszusetzen ist, sollte keine Fehlermeldung angezeigt werden. Mit "Wir bieten unseren Service in diesem Bereich nicht an" haben Sie Technologieprobleme hinter sich gelassen und sind auf geschäftliche Probleme eingegangen. Daher bin ich nicht sicher, ob ein HTTP-Fehler angemessen wäre. Ich denke, Sie sollten 200 und (oder 302 und weiterleiten an) eine entsprechende Nachricht geben: "Entschuldigung, unser Service ist in Ihrer Region noch nicht verfügbar. Aber wir werden expandieren. Schauen Sie Ende 2019 wieder vorbei!" oder was auch immer die Marketingabteilung vorhat.
— Ivanivan
7
Aus der Frage, ob Sie den gesamten Zugriff auf die API basierend auf dem Standort des Clientcomputers blockieren möchten (Geo-IP?) Oder ob Sie den Antwortcode für eine bestimmte fehlgeschlagene API-Anforderung anfordern (z. B. book? Address = 123_example_st_london), ist nicht ersichtlich. . Ist der Standort Teil der Eingabe, oder haben Sie den Standort des Kunden auf andere Weise?
— Ben

Antworten:

102

Jeder HTTP-Fehlercode wäre unangemessen. Aus HTTP-Sicht gibt es keinerlei Fehler oder Probleme, daher sollte es sich um einen Wert im Bereich von 200 handeln. Sie informieren einige Ihrer Benutzer höflich darüber, dass sie nicht bedient werden, indem Sie ein Dokument zurücksenden, das sie darüber informiert. Und das geht alles gut.

Der Benutzer kann Ihre Anwendung nicht verwenden . Das ist eine bewusste Entscheidung, die von Ihrer Geschäftslogik getroffen wurde, kein Missgeschick. Auf der HTTP-Ebene ist alles Honky Dory.

Bearbeiten

Es sieht so aus, als ob wir hier einen Konflikt zwischen alter und neuer Schule sehen. Bei der Entwicklung von HTTP gab es keine Webdienste, kein SOAP, kein JSON und keine REST-Prinzipien. Als Protokoll über TCP wurde dies bereits als (nahe) Anwendungsebene angesehen und viele übergeordnete Statuscodes wurden definiert. Als das Web für umfassendere Dienste auf hoher Ebene genutzt wurde und ein gemeinsames Mittel zum Transportieren von "Umschlägen" erforderlich war, nutzten die Designer HTTP, anstatt ein neueres und saubereres Protokoll zu definieren, nur weil HTTP allgegenwärtig war.

In einem modernen Webservice-Kontext ist HTTP in der Tat kaum mehr als eine blöde Transportschicht, und die meisten seiner Codes gelten möglicherweise als nicht anwendbar oder veraltet. Wählen Sie einfach eine aus, da sie Ihrem Anwendungsstatus sehr nahe kommt und sich zufällig in dieser Liste befindet, die früher bedeutete, dass etwas harmlos erscheinen könnte, aber ich denke, es würde eine falsche Nachricht senden. Sie möchten nicht, dass HTTP diese regulierende Rolle in einem Webdienstkontext spielt.

— Martin Maat
quelle
56
Nach dieser Logik sollte jeder Anwendungsfehler als 200 zurückgegeben werden. Alle Anforderungen sollten POST sein, auch Löschungen. Dieser Ansatz behandelt HTTP als undurchsichtiges Transportprotokoll - wie TCP. So werden Webdienst-APIs normalerweise nicht behandelt - sie versuchen, die HTTP-Semantik als Standardsprache für APIs zu nutzen. Warum nicht 401 für Unauthorized zurückgeben, anstatt 200 mit einem benutzerdefinierten, nicht standardmäßigen Fehlercode zurückzugeben?
— Avner Shahar-Kashtan
31
Nach dieser Logik sollte keine Anwendung jemals eine Antwort im Bereich 400 zurückgeben. Dies ist genau die Art von Bedingung, für die der Bereich von 400 Antworten gilt. Gilt Ihr erster Satz auch für alle zukünftigen Antworten sowie für diejenigen, die vor Ihnen gepostet wurden?
— Dawood ibn Kareem
31
Ich muss hier zustimmen, dass dies nur eine einfache 200 ist. Der Benutzer hat eine Frage gestellt, wir haben sie verstanden, wir kennen die richtige Antwort und wir haben ihm die Antwort gegeben (was zufällig "Nein" ist). Alles ist gut in HTTP Land.
— Lee Daniel Crocker
8
Hehe ... schnelle Reise von "Das ist nicht wirklich ein Fehler" nach "Also, du sagst, nichts ist jemals ein Fehler?"
— Svidgen
28
Diese. "Sie haben versucht, auf eine nicht vorhandene URL zuzugreifen" unterscheidet sich stark von "Unser Unternehmen ist in Ihrer Region nicht tätig". Nur einer hat etwas mit HTTP zu tun.
— CJ Dennis
87

5xxFehler sind Serverfehler - auf dem Server ist ein Fehler aufgetreten. Insbesondere zeigt ein 503 an, dass:

Der Server kann die Anforderung derzeit aufgrund einer vorübergehenden Überlastung oder einer geplanten Wartung nicht verarbeiten

4xxFehler sind Clientfehler - Der Client sendet eine Anforderung, die der Server nicht erfüllen kann oder will. Insbesondere ein 403 zeigt das an

Der Server hat die Anforderung verstanden, lehnt sie jedoch ab. Ein Server, der veröffentlichen möchte, warum die Anforderung verboten wurde, kann diesen Grund in der Antwortnutzlast (falls vorhanden) beschreiben. [..] Eine Anfrage kann jedoch aus Gründen, die nicht mit den Anmeldeinformationen zusammenhängen, verboten sein.

Ich würde behaupten, dass dies 503eindeutig falsch ist, da es sich nicht um ein vorübergehendes Problem handelt. Sie unterstützen Anfragen in diesem Bereich (Zeitraum) nicht. Es könnte argumentiert werden, dass Sie möglicherweise hoffen, den Bereich zu unterstützen, der Code soll jedoch einen Header enthalten, der angibt, wann der Client es erneut versuchen kann. "In 6 Monaten" hält sich nicht an die Absicht.

403 ist eine bessere Wahl, da Ihr Dienst nur Anfragen von bestimmten Gebietsschemas verbietet.

— Eric Stein
quelle
403 ist für Fälle vorgesehen, in denen der Zugriff verboten ist und der Client nichts dagegen unternehmen kann. Aber in diesem Fall kann der Kunde (mit Ihrem Laptop oder Telefon ins Auto), so dass 403 unangemessen ist.
— gnasher729
2
@ gnasher729 4xx-Fehler beziehen sich auf Dinge, die der Client möglicherweise beheben kann, einschließlich 403. Die (verknüpfte) Spezifikation gibt speziell an, dass der Client es mit verschiedenen Anmeldeinformationen erneut versuchen kann (vorausgesetzt, die Anmeldeinformationen waren das Problem).
— Jaxad0127
22
@ gnasher729 403 heißt nicht, dass der Mensch nichts dagegen unternehmen kann. Dies bedeutet, dass der Browser nichts dagegen unternehmen kann. Der Mensch kann jederzeit ein Passwort zurücksetzen, mit dem Administrator sprechen oder in diesem Fall in eine andere Stadt ziehen.
— Slebetman
1
@ gnasher729 Der Client ist nicht der Benutzer.
— Captain Man
10
5xx = Hoppla, bitte warten Sie, bis das Problem behoben ist. 4xx = Es tut uns leid, aber aus politischen Gründen können wir Ihre Anfrage derzeit nicht bearbeiten. Hier ist, warum ....
— candied_orange
46

Weder von denen.

Wenn Ihre API gut gestaltet ist, enthält die URL den Namen der Stadt, z

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

oder

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

Da die IP-Geolokalisierung unzuverlässig ist, verwenden Ihre Benutzer möglicherweise VPNs, möchten Ihre Benutzer möglicherweise eine Mitfahrgelegenheit für eine andere Person gratulieren usw. Es liegt in der Verantwortung des API-Clients , eine Stadt basierend auf dem Standort des Benutzers vorzuschlagen . Normalerweise verfügt der Client ohnehin über viel bessere Ressourcen zum Bestimmen des Standorts des Benutzers (z. B. den Standortdienst eines Mobilgeräts).

Sobald Sie das getan haben, die richtige Antwort auf 

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

oder

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

wird offensichtlich: 404 Not Found : Es ist keine Ressource vorhanden, um eine Fahrt bei SomeUnsupportedCity anzukündigen.

— Heinzi
quelle
6
Dies sollte die akzeptierte Antwort sein: Beim API-Design geht es nicht nur darum, alte numerische Codes einzuhalten, und das Szenario mit VPNs usw. ist ziemlich realistisch.
— Edoardo
10
Ich muss dem nicht zustimmen. Wenn Sie den Namen der Stadt in die URL aufnehmen, kann dies zu Problemen führen, da der Client gezwungen ist, einen Städtenamen basierend auf dem Standort zu ermitteln. Das Ergebnis gefällt Ihnen möglicherweise nicht. Sind Sie zum Beispiel in Los Angeles oder Beverly Hills? London oder Westminster? Was passiert, wenn der Kunde denkt, dass es sich um Richardson handelt, Sie jedoch möchten, dass eine API den gesamten Raum Dallas abdeckt? Es wäre eine bessere Idee für den Kunden, nur die Abhol- / Abgabestellen anzugeben. Der Server kann feststellen, ob er sich im Servicebereich befindet, und entsprechend reagieren.
— Zach Lipton
11
@ZachLipton Ich bin mir ziemlich sicher, dass die Städtenamen nur ein Beispiel waren. Es hängt von den tatsächlichen Geschäftsregeln des OP ab, wie sie "Stadt" oder "Ort" definieren. Es könnte auch eine Koordinate sein.
— Bergi
1
@ZachLipton nein, der Punkt hier ist nicht, dass der Dienst die Client-IP verwendet, um den Standort zu verstehen, das ist einfach falsch
— Edoardo
3
@eddyce Ich stimme zu, dass die Verwendung der Client-IP aus vielen Gründen eine schlechte Idee ist. Ich sage, dass / API / Vienna / HailRide ebenfalls problematisch ist, da der Client Standorte in Städtenamen konvertieren muss. Dies ist keine 1-zu-1-Zuordnung, die den Bereichen entspricht, in denen ein Unternehmen geschäftlich tätig ist.
— Zach Lipton
26

Dies scheint eine runde Loch / quadratische Pflock-Frage zu sein. Warum muss Ihre einzige Antwort ein HTTP-Code sein? HTTP-Fehlercodes können möglicherweise nicht alle Anwendungsfälle abdecken.

Alle Ihre API-Aufrufe sollten zusätzliche Nachrichten enthalten, die zurückkommen - dh eine kleine JSON-Fehlermeldung. Geben Sie ihnen eine 403 (weil sie in Anbetracht des Speicherorts nicht die Berechtigung haben, die API zu verwenden) und geben Sie eine zusätzliche Information zurück, wie Sie vorschlagen.

Wenn Sie dies nicht tun, werden Sie beim nächsten Mal gefragt, welcher HTTP-Fehlercode zurückgegeben werden soll, wenn der Benutzer nach einem SUV gefragt hat, aber nur ein Prius verfügbar ist.

— stdunbar
quelle
5
+1 für deinen letzten Satz. Fasst es gut zusammen.
— LoztInSpace
1
Nun, das müsste eindeutig eine Art 3xx-Umleitung sein. ;)
— Brandon Mintern
Der letzte Fall rechtfertigt wahrscheinlich eine 4xx-Antwort: Der Benutzer hat eine Anfrage gestellt, die der Server nicht erfüllen kann. Es wäre 400, wenn die Auswahl eine ungültige Eingabe wäre, oder 404, wenn der Ort selbst einfach nicht existiert. Obwohl es 200 sein könnte, wenn es ein Suchkriterium ist und es nur keine Übereinstimmungen gibt.
— jpmc26
11

Ein paar machen Sinn.

403 Verboten aus den Gründen, die Eric Stein in seiner Antwort erwähnt . Sie können verschiedene Informationen verwenden, die von der Anforderung bereitgestellt werden, um zu bestimmen, wo sich der Client befindet und wer der Client ist. Auf der Grundlage dieser Anforderung kann oder will der Server keine Antwort geben.

Ich würde jedoch auch 451 Aus rechtlichen Gründen nicht verfügbar als möglichen Rückgabestatus für einige Fälle anführen. Dieser Status setzt voraus, dass Sie (in den Überschriften) einen Link zu den einschlägigen Rechtsvorschriften einfügen. Dies gilt insbesondere für Fälle, in denen es für den Kunden nicht legal ist, auf Ihre Ressourcen zuzugreifen, und in denen in einer nicht unterstützten Region oder Region kein allgemeinerer Fall für den Kunden vorliegt.

Ich würde die 5xx-Reihe von Status vermeiden - diese weisen häufig auf serverseitige technische Probleme hin. Dies scheint hier nicht der Fall zu sein.

— Thomas Owens
quelle
Wahrscheinlich liegt der Grund in diesem Fall darin, dass es keinen Sinn macht, den Benutzer über Autos zu informieren, die sich nicht in ihrer Stadt befinden. So ist es nicht der Fall für 451
— max630
4
@ max630 Das kann man von der Frage nicht annehmen. 403 Verboten ist höchstwahrscheinlich die richtige Wahl. Wenn es jedoch gesetzliche Einschränkungen für den Dienst gibt, kann stattdessen der spezifischere 451 verwendet werden. 451 wird oft als spezifischere Version von 403 für ganz bestimmte Anwendungsfälle angesehen, daher ist es sinnvoll, sie aufzurufen.
— Thomas Owens
8
@ max630 - es ist durchaus möglich, dass 451 hier angebracht ist. In vielen Ländern müssen Betreiber dieser Art von Diensten bei den regionalen Behörden registriert sein, bevor sie den Dienst anbieten. Es könnte ihnen gesetzlich untersagt sein, bestimmte Anfragen zu bearbeiten, wenn sie von außerhalb des Gebiets stammen.
— Jules
5

Wenn die Einschränkung aus rechtlichen Gründen besteht, lautet der entsprechende HTTP-Fehlercode HTTP 451 (aus rechtlichen Gründen nicht verfügbar).

Dies wird in der Regel für Material verwendet, das aufgrund von DMCA-Maßnahmen oder Klagen aufgrund von Belästigungskampagnen oder Ähnlichem widerrufen wurde. Der Sinn und der Buchstabe der Antwortdefinition lauten jedoch :

In diesem Dokument wird ein HTTP-Statuscode (Hypertext Transfer Protocol) angegeben, der verwendet wird, wenn der Ressourcenzugriff aufgrund gesetzlicher Anforderungen verweigert wird.

Der Code selbst ist ein Verweis auf Fahrenheit 451 von Ray Bradbury.

— flauschige
quelle
3

Die Leute vergessen oft, dass HTTP-Statuscodes erweiterbar sind.

HTTP-Statuscodes sind erweiterbar. HTTP-Anwendungen müssen nicht die Bedeutung aller registrierten Statuscodes verstehen, obwohl ein solches Verständnis offensichtlich wünschenswert ist. Anwendungen MÜSSEN jedoch die Klasse eines Statuscodes, wie durch die erste Ziffer angegeben, verstehen und jede nicht erkannte Antwort als dem x00-Statuscode dieser Klasse äquivalent behandeln, mit der Ausnahme, dass eine nicht erkannte Antwort NICHT zwischengespeichert werden MUSS. Wenn der Client beispielsweise den unbekannten Statuscode 431 empfängt, kann er davon ausgehen, dass die Anforderung fehlerhaft ist, und die Antwort so behandeln, als hätte er den Statuscode 400 erhalten. In solchen Fällen MÜSSEN Benutzeragenten dem Benutzer die Entität präsentieren, die mit der Antwort zurückgegeben wurde.

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

Sie können jederzeit einen eigenen Statuscode im Bereich 400 erstellen, der von Ihrer API und Client-Anwendung verwendet wird.

— Badeente
quelle
Hmm ... ist möglicherweise nicht erforderlich, wenn die Anforderung einen Expect token;city="Albequerque"Header enthält. Dann wäre die geeignetste Antwort 417, Erwartung gescheitert. tools.ietf.org/html/rfc2616#section-10.4.18 Vorausgesetzt natürlich, dass dies für einen Webdienst ist.
— Berin Loritsch
Möglicherweise nicht erforderlich @BerinLoritsch, aber anstatt zu versuchen, eine Situation in einen vorhandenen Code einzufügen, ist es möglicherweise besser, nur einen benutzerdefinierten Code zu verwenden.
— RubberDuck
0

Zuerst dachte ich, 503, weil die Beschreibung "Dienst nicht verfügbar" mit dem Problem in Einklang zu stehen scheint, aber in Bezug auf die Definitionen ist 503 wirklich spezifisch für die Nichtverfügbarkeit von Servern. Wenn Sie mehr darüber nachdenken, teilen Sie dem Client mit, dass ein Problem mit der Anforderung vorliegt und nicht, dass ein serverseitiges Problem vorliegt.

403 ist näher, weil Sie dem Benutzer mitteilen, dass Sie die Nachricht erhalten und verstanden haben, der Server jedoch nicht bereit ist, sie zu befriedigen. Dies kann verwirrend sein, so dass eine Texterklärung hinzugefügt werden kann, um das Szenario zu beschreiben. Gemäß RFC ist 404 auch ein gültiger Ersatz für diesen Code.

403 oder 404 scheinen die nächsten zu sein, es sei denn, jemand hat sich einen neuen Code dafür ausgedacht.

— JimmyJames
quelle
Auf keinen Fall ein 5xx-Code, da dies impliziert, dass der Versuch, genau dieselbe Anforderung später auszuführen, möglicherweise erfolgreich ist. Ein 4xx-Code weist den Client definitiv an, es nicht erneut zu versuchen, ohne zumindest einen Teil der Anforderung zu ändern (in diesem Fall das Feld "Servicestandort").
— Toby Speight
0

Sie sollten die Beschreibung des Fehlers mit dem von Ihnen angegebenen Code abgleichen:

  • wenn du sagst Service not available in your area.dann solltest du ein geben 404weil du behauptest das der service nicht verfügbar ist .

  • wenn du das sagst You are not authorized for this service in your area.dann solltest du a geben 403weil du behauptest das der anrufer nicht autorisiert ist .

Ich würde für die Sekunde gehen.

— Edoardo
quelle
6
Bei 404 geht es nicht um Verfügbarkeit , sondern um Existenz . Nur weil ein Dienst unter bestimmten Umständen nicht verfügbar ist, sollten Sie keine 404-Antwort bereitstellen, es sei denn, Sie möchten, dass die Leute glauben, dass er überhaupt nicht vorhanden ist. Eine 404-Antwort wäre für diese Situation bedeutungslos.
— Jules
@jules Entsprechend der Spezifikation für 403 (die veraltet sein könnte): "Wenn der Server diese Informationen dem Client nicht zur Verfügung stellen möchte, kann stattdessen der Statuscode 404 (Nicht gefunden) verwendet werden. " Wenn also 403 in Ordnung ist, dann wäre auch 404, aber nicht unbedingt aus dem angegebenen Grund.
— JimmyJames
@JimmyJames - ja, es liegt innerhalb der Spezifikation, ist aber eine wirklich schlechte Idee, da dies das Debuggen von Problemen extrem erschwert. Nicht das, was Sie in einer API wollen.
— Jules
3
@Jules Der Dienst existiert in einigen Bereichen nicht. Ähnlich wie es viele kleine Läden gibt, die nur in meiner Stadt existieren, fragt man sie in einer anderen Stadt, lautet die richtige Antwort "existiert nicht".
— Andy
ehmm über "Existenz" eines Service-URL-Pfades zu sprechen, ist am wenigsten philosophisch. Aus Gründen der Klarheit, wenn Sie einen Pfad veröffentlichen, müssen Sie eine Antwort geben die Situation.
— Edoardo
0

Es gibt einen aktuellen Internet-Entwurf (der am 31. Dezember 2018 abläuft), der Änderungen des Status " HTTP 451 aus rechtlichen Gründen nicht verfügbar" vorschlägt . Der Entwurf schlägt vor, dass eine 451-Antwort einen geo-scope-blockHeader enthalten sollte, der "der durch Kommas getrennten Liste der in [ISO.3166-1] definierten Alpha-2-Ländercodes entspricht". Im Entwurf ist jedoch auch festgelegt, dass der Code 451 nicht verwendet werden sollte, "um einem Betreiber den Zugriff auf eine Ressource auf der Grundlage einer vom Betreiber festgelegten Richtlinie zu verweigern (im Gegensatz zu einer gesetzlichen Anforderung an den Betreiber)".

Vorausgesetzt, Sie haben keine rechtliche Anforderung für den Geoblock, ist 451 nicht der richtige Code. Was ist dann der richtige Code? Nun, zahlreiche andere Antworten haben bereits 403 Forbidden vorgeschlagen , aber sie scheinen alle "meinungsbasiert" zu sein. Schauen wir uns also an, was andere tun:

Es gibt also keine universelle Lösung. Sie müssen nur eine auswählen, die Ihrer Situation am besten entspricht. Aber je nachdem, was Sie wählen, müssen Sie das eigentliche Problem im Antworttext erklären .

Ich würde sagen, es wäre nichts Falsches, nur einen benutzerdefinierten HTTP-Statuscode anzugeben, wie RubberDuck bereits geantwortet hat . Ein benutzerdefinierter Statuscode im 400er-Bereich könnte sogar ein ziemlich guter Anruf sein, da dies definitiv die Aufmerksamkeit der Entwickler auf sich zieht, wenn sie so etwas wie "HTTP-Status 499" sehen. Ein "403" ist zu einfach als " OK, also habe ich mein Passwort falsch eingegeben, lasst uns stattdessen etwas anderes versuchen " zu übergeben, und das führt zu verschwendeten Stunden.

— Null eins
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.