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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

• Amazon CloudFront utilise 403 Forbidden
• Apparemment, Twitter renvoie 200 OK mais explique le problème dans le contenu JSON - mais il s’agit de tweets individuels, pas de l’API complète.
• Pinterest utilise 451
• Le plugin WordPress IP Geo Block vous permet de choisir n'importe quel code existant

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.