Quel devrait être le code de statut http pour l'erreur «Le service n'est pas disponible dans votre région»?

51

Notre service est présent dans 5 villes. Si quelqu'un essaie d'appeler notre API de service depuis une autre ville, nous voulons lancer cette erreur Service not available in your area.

La question est, quel est le code http approprié serait pour cette erreur?

  • 503 Service Indisponible
  • 403: interdit

ou autre chose?

api api-design http Shaharyar
la source
52
"Si quelqu'un essaie d'appeler notre API de service depuis une autre ville", notez que la géolocalisation IP est souvent fausse. Si vous interdisez à un utilisateur dont l'adresse IP est géolocalisée dans une autre ville, il est très probable que vous verrouillez les utilisateurs légitimes.
Peter Green
43
Est-ce que je ne suis pas autorisé à héler une balade pour mon enfant, qui est dans une autre ville et doit venir à l'aéroport pour me rendre visite?
Dawood dit réintégrer Monica
29
Bien que HTTP 451 (RFC 7725) ne soit pas une réponse à la question, il pourrait être utile aux futurs lecteurs qui trouveraient cette question. Son objectif principal est d'indiquer que le contenu n'est pas disponible en raison d'une demande légale, d'une action ou d'une restriction (droit d'auteur, ordonnance d'un tribunal, etc.)
Tyzoid
34
S'il n'y a rien d'anormal dans la connectivité réseau, l'authentification, les erreurs internes à l'application et les entrées syntaxiquement valables, il ne devrait pas y avoir de message d'erreur. Avec "nous n'offrons pas notre service dans ce domaine", vous avez laissé des problèmes de technologie et des problèmes d'entreprise. Je ne suis donc pas sûr qu'une erreur HTTP conviendrait. Je pense que vous devriez donner 200 et (ou 302 et rediriger vers) un message approprié à propos de "Désolé, notre service n'est pas disponible dans votre région - pas encore. Mais nous sommes en pleine expansion - Revenez à la fin de 2019!" ou ce que le service marketing propose.
ivanivan
7
La question ne permet pas de savoir si vous souhaitez bloquer tous les accès à l'API en fonction de l'emplacement de l'ordinateur client (adresse IP géographique?) Ou si vous demandez le code de réponse pour une demande d'API ayant échoué (par exemple, book? Address = 123_example_st_london). . L'emplacement fait-il partie de l'entrée ou avez-vous l'emplacement du client d'une autre manière?
Ben

Réponses:

101

Tout code d'erreur HTTP serait inapproprié. Il n'y a pas d'erreur ou de problème d'aucune sorte du point de vue HTTP, il devrait donc s'agir d'une erreur de l'ordre de 200. Vous informez poliment certains de vos utilisateurs qu’ils ne seront pas réparés en leur renvoyant un document les informant de la situation. Et tout se passe bien.

L'utilisateur ne pourra pas utiliser votre application . C’est une décision consciente prise par votre logique d’entreprise, pas un malheur. Au niveau HTTP, tout est à l'honneur.

Modifier

On dirait que ce que nous observons ici est un affrontement entre la vieille école et la nouvelle école. Lors de la conception de HTTP, il n'y avait pas de services Web, pas de SOAP, pas de JSON, pas de principes REST. En tant que protocole supérieur à TCP, cela était déjà considéré (proche du) niveau de l'application et de nombreux codes d'état de haut niveau ont été définis. Lorsque le Web a commencé à être utilisé pour des services plus riches et de haut niveau et qu'un moyen commun de transporter des "enveloppes" était requis, les concepteurs ont utilisé le protocole HTTP plutôt que de définir un protocole plus récent et plus clair, simplement parce que HTTP était omniprésent.

Ainsi, dans un contexte de service Web moderne, HTTP n’est en réalité qu’une simple couche de transport stupide et la plupart de ses codes peuvent être considérés comme non applicables ou obsolètes. Choisissez-en un simplement parce que cela se rapproche de l'état de votre application et qu'il se trouve dans cette liste qui signifiait autrefois que quelque chose peut sembler inoffensif, mais je pense que cela enverrait un mauvais message. Vous ne voulez pas que HTTP joue ce rôle de régulation dans un contexte de service Web.

Martin Maat
la source
56
Selon cette logique, toute erreur d'application doit être renvoyée sous la forme 200. Toutes les demandes doivent être des requêtes POST, même des suppressions. Cette approche considère HTTP comme un protocole de transport opaque, comme le protocole TCP. Ce n’est pas ainsi que les API de service Web sont généralement traitées: elles essaient d’utiliser la sémantique HTTP comme langage standard pour les API. Pourquoi ne pas renvoyer 401 pour Unauthorized, plutôt que 200 avec un code d'erreur personnalisé non standard?
Avner Shahar-Kashtan
31
Selon cette logique, aucune application ne doit jamais renvoyer de réponse dans la plage 400. C’est précisément le type de condition à laquelle la plage de 400 réponses est destinée. De plus, votre première phrase s'applique-t-elle à toutes les réponses futures, ainsi qu'à celles postées avant la vôtre?
Dawood dit réintégrer Monica le
31
Je dois admettre ici qu'il ne s'agit que d'un simple 200. L'utilisateur a posé une question, nous l'avons compris, nous connaissons la bonne réponse et nous lui avons fourni la réponse (qui se trouve être "Non"). Tout va bien en HTTP.
Lee Daniel Crocker
8
Héhé ... bref voyage de "ce n'est pas vraiment une erreur" à "alors, vous dites que rien n'est jamais une erreur?"
svidgen
28
Cette. "Vous avez essayé d'accéder à une URL qui n'existe pas" est très différent de "Notre société ne fonctionne pas dans votre région". Un seul a quelque chose à voir avec HTTP.
CJ Dennis
87

5xxles erreurs sont des erreurs de serveur - une erreur s'est produite sur le serveur. En particulier, un 503 indique que:

le serveur est actuellement incapable de traiter la demande en raison d'une surcharge temporaire ou d'une maintenance planifiée

4xxles erreurs sont des erreurs de client - le client fait une demande que le serveur ne peut pas ou ne veut pas remplir. En particulier, un 403 indique que

le serveur a compris la requête mais refuse de l’autoriser. Un serveur qui souhaite rendre public la raison pour laquelle la demande a été interdite peut décrire cette raison dans la charge utile de la réponse (le cas échéant). [..] Cependant, une demande peut être interdite pour des raisons autres que les identifiants.

Je dirais que 503c'est manifestement incorrect, parce que ce n'est pas un problème temporaire - vous ne supportez pas les demandes dans ce domaine, point final. L'argument pourrait être que vous espériez éventuellement supporter la zone, mais le but du code est d'inclure un en-tête indiquant le moment où le client peut réessayer. "Dans 6 mois" n'adhère pas à l'intention.

403 est un meilleur choix car votre service interdit simplement les demandes de certains lieux.

Eric Stein
la source
403 est destiné aux cas où l'accès est interdit et où le client ne peut rien y faire. Mais dans ce cas, le client peut (entrer dans la voiture avec votre ordinateur portable ou votre téléphone), 403 n'est donc pas approprié.
gnasher729
2
@ gnasher729 Les erreurs 4xx concernent les problèmes que le client peut résoudre, notamment 403. La spécification (liée) indique spécifiquement que le client peut réessayer avec différentes informations d'identification (en supposant que les informations d'identification étaient la cause du problème).
jaxad0127
22
@ gnasher729 403 ne signifie pas que l'humain ne peut rien y faire. Cela signifie que le navigateur ne peut rien y faire. L’utilisateur peut toujours réinitialiser son mot de passe, s’adresser à l’administrateur ou, dans ce cas, se déplacer dans une autre ville.
slebetman
1
@ gnasher729 Le client n'est pas l'utilisateur.
Captain Man
10
5xx = Oups notre mal, accrochez-vous pendant que nous résolvons le problème. 4xx = Nous sommes désolés, mais nous ne sommes pas en mesure de répondre à votre demande pour l'instant. Voici pourquoi ....
candied_orange
46

Ni de ceux-là.

Si votre API est bien conçue, l’URL comprend le nom de la ville, par exemple

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

ou

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

Dans la mesure où la géolocalisation IP n'est pas fiable, vos utilisateurs peuvent utiliser des réseaux privés virtuels (VPN), vos utilisateurs peuvent vouloir saluer un tour pour quelqu'un d'autre, etc. Suggérer une ville en fonction de l'emplacement de l'utilisateur relève de la responsabilité du client API . En règle générale, le client dispose de bien meilleures ressources pour déterminer l'emplacement de l'utilisateur (par exemple, le service de localisation d'un périphérique mobile).

Une fois que vous avez fait cela, la bonne réponse à 

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

ou

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

devient évident: 404 Not Found : il n'existe aucune ressource pour héler un tour chez SomeUnsupportedCity.

Heinzi
la source
6
Cela devrait être la réponse acceptée: la conception d'API ne consiste pas uniquement à se conformer aux anciens codes numériques, et le scénario relatif aux vpn, etc., est tout à fait réaliste.
Edoardo
10
Je ne suis pas d'accord avec cela. Le fait d'inclure le nom de la ville dans l'URL pourrait entraîner toutes sortes de problèmes, car il oblige le client à déterminer un nom de ville en fonction de l'emplacement, et vous risquez de ne pas aimer le résultat. Par exemple, êtes-vous à Los Angeles ou à Beverly Hills? Londres ou Westminster? Que se passe-t-il si le client pense que c'est à Richardson, mais que vous voulez une API pour desservir toute la région de Dallas? Ce serait une meilleure idée pour le client de simplement fournir les lieux de ramassage / dépose; le serveur peut déterminer s'il se trouve dans la zone de service et réagir en conséquence.
Zach Lipton
11
@ZachLipton Je suis presque sûr que les noms de ville n'étaient qu'un exemple. Cela dépend des règles commerciales réelles du PO, qui définissent la "ville" ou le "lieu". Cela pourrait aussi bien être une coordonnée.
Bergi
1
@ZachLipton non, le problème ici est que le service n'utilise pas l'adresse IP du client pour comprendre l'emplacement; c'est tout à fait faux
Edoardo
3
@eddyce Je suis d'accord pour dire que l'utilisation de l'IP client est une mauvaise idée pour plusieurs raisons. Je dis que / API / Vienna / HailRide est également sujet à des problèmes, car il oblige le client à convertir des emplacements en noms de villes, et ce n'est pas un mappage 1 à 1 qui correspond aux zones dans lesquelles une entreprise exerce ses activités.
Zach Lipton
26

Cela ressemble à une question trou rond / cheville carrée. Pourquoi votre seule réponse doit-elle être un code HTTP? Les codes d'erreur HTTP ne peuvent éventuellement couvrir tous les cas d'utilisation.

Tous les appels de votre API doivent avoir une messagerie supplémentaire, par exemple un petit message d'erreur JSON. Donnez-leur un 403 (car, en réalité, ils ne sont pas autorisés à utiliser l'API, en fonction de l'emplacement) et renvoyez une information supplémentaire, comme vous le suggérez.

Si vous ne le faites pas, la prochaine fois vous demanderez quel code d'erreur HTTP à renvoyer lorsque l'utilisateur a demandé un SUV mais seule une Prius est disponible.

stdunbar
la source
5
+1 pour votre dernière phrase. Résume bien.
LoztInSpace
1
Eh bien, il faudrait clairement que la redirection 3xx soit d’une certaine manière. ;)
Nom réel expurgé le
Le dernier cas justifie probablement une réponse 4xx: l’utilisateur a fait une demande que le serveur ne peut pas remplir. Il s'agirait de 400 si le choix était une entrée non valide ou de 404 si l'emplacement lui-même n'existait pas. Bien que cela puisse être 200 si c'est un critère de recherche et qu'il n'y a pas de correspondance.
jpmc26
11

Quelques uns ont un sens.

403 Interdit, pour les raisons mentionnées par Eric Stein dans sa réponse . Vous pouvez utiliser diverses informations fournies par la demande pour déterminer où se trouve le client et qui est le client. Sur la base de cette demande, le serveur ne peut pas ou ne veut pas répondre.

Cependant, je proposerais également 451 Non disponible pour des raisons juridiques comme statut de retour possible dans certains cas. Ce statut suppose que vous incluiez (dans les en-têtes) un lien vers la législation pertinente. C'est spécifiquement pour les cas où il n'est pas légal pour le client d'accéder à vos ressources, et non un cas plus général du client existe dans une région ou une zone non prise en charge.

J'éviterais la série d'états 5xx - ils indiquent souvent des problèmes techniques côté serveur. Cela ne semble pas être le cas ici.

Thomas Owens
la source
La raison en est probablement que cela n'a aucun sens de parler à l'utilisateur de voitures qui ne sont pas dans leur ville. Ce n’est donc pas le cas pour 451
max630
4
@ max630 Vous ne pouvez pas supposer cela d'après la question. 403 Interdit est probablement le bon choix. Cependant, s'il existe des restrictions légales sur le service, le 451 plus spécifique peut être utilisé à la place. 451 est souvent considéré comme une version plus spécifique de 403 pour des cas d'utilisation très particuliers, il est donc logique de le signaler.
Thomas Owens
8
@ max630 - il est tout à fait possible que 451 soit approprié ici. De nombreuses juridictions exigent que les opérateurs de ce type de service soient enregistrés auprès des autorités régionales avant de fournir le service. Ils pourraient en fait être légalement interdits de traiter certaines demandes si elles sont originaires de l'extérieur de la zone.
Jules
5

Si la restriction est due à des raisons légales, le code d'erreur HTTP approprié est HTTP 451, "Non disponible pour des raisons légales".

Ceci est généralement utilisé dans le cas de matériel révoqué en raison d'une action de la DMCA ou de poursuites judiciaires en raison de campagnes de harcèlement ou similaires, mais l' esprit et la lettre de la définition de la réponse indiquent:

Ce document spécifie un code d'état HTTP (Hypertext Transfer Protocol) à utiliser lorsque l'accès aux ressources est refusé en raison de contraintes légales.

Le code lui-même fait référence à Fahrenheit 451 de Ray Bradbury.

duveteux
la source
3

Les gens oublient souvent que les codes de statut HTTP sont extensibles.

Les codes de statut HTTP sont extensibles. Les applications HTTP ne sont pas obligées de comprendre la signification de tous les codes d'état enregistrés, bien qu'une telle compréhension soit évidemment souhaitable. Cependant, les applications DOIVENT comprendre la classe de tout code d'état, comme indiqué par le premier chiffre, et traiter toute réponse non reconnue comme équivalente au code d'état x00 de cette classe, à l'exception du fait qu'une réponse non reconnue NE DOIT PAS être mise en cache. Par exemple, si un code d'état non reconnu de 431 est reçu par le client, celui-ci peut supposer en toute sécurité qu'il y avait un problème avec sa demande et traiter la réponse comme s'il avait reçu un code d'état 400. Dans de tels cas, les agents d'utilisateur DEVRAIENT présenter à l'utilisateur l'entité renvoyée avec la réponse.

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

Vous pouvez toujours créer votre propre code de statut dans la plage 400 pour une utilisation par votre API et votre application client.

Canard en caoutchouc
la source
Hmm ... peut ne pas être nécessaire si la demande incluait un en- Expect token;city="Albequerque"tête. Alors la réponse la plus appropriée serait 417, attente échouée. tools.ietf.org/html/rfc2616#section-10.4.18 En supposant bien sûr qu'il s'agisse d'un service Web.
Berin Loritsch
Peut-être pas nécessaire @BerinLoritsch, mais plutôt que d'essayer de forcer l'ajustement d'une situation à un code existant, il peut être préférable de simplement flatter et utiliser un code personnalisé.
RubberDuck
0

Au début, je pensais que 503 parce que la description "service indisponible" semble correspondre au problème, mais en regardant les définitions , 503 est vraiment spécifique à l'indisponibilité du serveur. En réfléchissant davantage, vous dites au client que la demande pose un problème, mais pas un problème côté serveur.

403 est plus proche parce que vous dites à l'utilisateur que vous avez bien compris le message, mais que le serveur ne veut pas le satisfaire. Cela peut prêter à confusion et une explication textuelle peut être ajoutée pour décrire le scénario. Selon la RFC, 404 est également un substitut valide pour ce code.

À moins que quelqu'un ait imaginé un nouveau code pour cela, 403 ou 404 semblent être les plus proches.

JimmyJames
la source
Ce n'est certainement pas un code 5xx, car cela implique que le fait d'essayer exactement la même demande ultérieurement pourrait réussir. Un code 4xx indique définitivement au client de ne pas réessayer sans modifier au moins une partie de la demande (dans ce cas, le champ "emplacement du service").
Toby Speight
0

Vous devez faire correspondre la description de l'erreur avec le code que vous donnez:

  • si vous dites, Service not available in your area.vous devriez donner un 404parce que vous prétendez que le service n'est pas disponible .

  • si vous dites, You are not authorized for this service in your area.vous devez donner un 403parce que vous prétendez que l'appelant n'est pas autorisé .

J'irais pour la seconde.

Edoardo
la source
6
404 ne concerne pas la disponibilité , mais l' existence . Tout simplement parce qu'un service n'est pas disponible dans certaines circonstances, vous ne devriez pas fournir de réponse 404 à moins que vous ne vouliez que les gens croient qu'il n'existe pas du tout. Une réponse 404 n'aurait aucun sens pour cette situation.
Jules
@jules Selon la spécification 403 (qui pourrait être obsolète): "Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404 (Introuvable) peut être utilisé à la place. " Donc, si 403 est OK, alors 404 le serait également, mais pas nécessairement pour la raison donnée.
JimmyJames
@ JimmyJames - Oui, c'est dans les spécifications, mais c'est une très mauvaise idée car cela rend les problèmes de débogage extrêmement difficiles. Pas ce que vous voulez dans une API.
Jules
3
@Jules Le service n'existe dans certaines régions. Comme dans beaucoup de petits magasins qui n'existent que dans ma ville, demander la bonne réponse à leur adresse dans une autre ville est "n'existe pas".
Andy
euhmm, parler d’existence d’un chemin d’URL de service est le moins - philosophique, pour plus de clarté, une fois que vous publiez un chemin, vous devez donner une réponse. 403 est la voie à suivre dans ce cas, avec une sorte de description verbale de la situation.
Edoardo
0

Un projet Internet actuel (qui expirera le 31 décembre 2018) propose de modifier le statut HTTP 451 non disponible pour des raisons de droit . L'ébauche suggère qu'une réponse 451 devrait contenir un en- geo-scope-blocktête qui devrait "correspondre à une liste de codes de pays alpha-2 séparés par des virgules définis dans [ISO.3166-1]". Toutefois, le projet précise également que le code 451 ne doit pas être utilisé "par un opérateur pour refuser l'accès à une ressource sur la base d'une politique spécifiée par l'opérateur (par opposition à une demande légale imposée à l'opérateur)".

Donc, en supposant que vous n’ayez pas de demande légale pour le géobloc, 451 n’est pas le bon code. Quel est le bon code alors? Eh bien, de nombreuses autres réponses ont déjà suggéré 403 Interdit , mais elles semblent toutes être "basées sur l'opinion", voyons ce que les autres font:

Donc, il n'y a pas de solution universelle, vous devrez simplement en choisir une qui conviendra le mieux à votre situation. Mais quel que soit votre choix, veillez à expliquer le problème dans le corps de la réponse .

Je dirais qu'il n'y aurait rien de mal à spécifier un code de statut HTTP personnalisé, comme RubberDuck déjà répondu . Un code de statut personnalisé dans la plage 400 pourrait en fait même être un très bon appel, car cela attirerait certainement l'attention des développeurs s'ils voyaient quelque chose comme "HTTP status 499". Un "403" est trop facile à passer comme " OK, alors je me suis trompé de mot de passe, essayons quelque chose d'autre à la place ", ce qui entraîne des heures perdues.

Zéro un
la source