Existe-t-il une norme pour les codes d'erreur/d'erreur?

Question

J'écris actuellement une API/quelques clients pour les parties d'échecs.

Les développeurs doivent accéder à l'API via un script (xhrframework.php) et soumettre les actions via GET. Il est possible qu'ils fassent des erreurs lorsqu'ils soumettent les actions (pas de PHPSESSID envoyé, pas de PHPSESSID valide, le déplacement n'était pas valide, ce n'est pas leur tour, ...). J'ai donc pensé aux possibilités d'affichage des erreurs. Je suis venu avec quelques idées sur la façon d'informer le programmeur, qu'il a commis une erreur:

1. par un message d'erreur en clair anglais
   • +: Il est clair que l'erreur devrait signifier
   • + : information comment corriger cette erreur peut être ajouté
   • -: le message pourrait changer mon anglais est pas très bon
   • -: la longueur du message diffère beaucoup - cela pourrait être important pour les programmeurs C
2. via ab constante de message d'erreur en anglais - INVALID_MOVE, NOT_YOUR_TURN, ...
   • + quelque chose comme WRONG_PHPSESSID, MISSING_PHPSESSID,: Il est compréhensible pour un être humain
   • 0: Il est presque certain que le message doesn « t changer
   • -: la longueur du message peut différer un peu
3. via un code d'erreur avec une table dans la documentation où le programmeur peut trouver le sens du code d'erreur
   • +: Le code d'erreur serait constante
   • +: La longueur de chaque code d'erreur pourrait être le même
   • -: Il est cryptique

Je thoguht la troisième solution pourrait être une bonne idée car le xhrframework.php ne devrait être accessible que par un programmeur qui a tout à fait pu prendre déjà un coup d'oeil à la documentation de l'API.

Maintenant, je voudrais savoir si une norme pour les messages d'erreur Web-API existe. Comment d'autres personnes (par exemple l'API Google Maps) ont-elles résolu ce problème? Dois-je simplement sortir une page vierge avec le contenu "ERREUR: 004" ou sans remplissage "ERREUR: 4"?

Quelles erreurs devraient obtenir quels numéros? Est-il logique de grouper les erreurs par leurs numéros, par ex. toutes les erreurs commençant par 1 étaient des erreurs d'authentification, toutes les erreurs avec deux erreurs de logique de jeu? Serait-il préférable de commencer par l'erreur 1 et d'utiliser chaque numéro?

Google Maps API

Si je fais un wrong call aux Google Maps JS-API, il retourne Java-Script avec un message en clair allemand (comme je vis en Allemagne, je suppose).

L'API Google Static Maps renvoie un message sous forme de texte en anglais clair si je crée un wrong call.

Answer 1

La plupart des services de l'API suivent le système de code d'erreur HTTP RFC2817 avec des plages de codes d'erreur pour les différents types d'erreur:

1xx: Informational - Request received, continuing process 
2xx: Success - The action was successfully received, understood, and accepted 
3xx: Redirection - Further action must be taken in order to complete the request 
4xx: Client Error - The request contains bad syntax or cannot be fulfilled 
5xx: Server Error - The server failed to fulfil an apparently valid request 

Dans un contexte API vous principalement utiliser les valeurs 4xx pour indiquer les conditions d'erreur à faire avec la validation des demandes. 49x sont généralement utilisés pour les conditions d'erreur de sécurité.

Answer 2

Il n'y a pas de norme, et pourquoi devrait-il y avoir? Les programmeurs utilisant votre interface doivent déjà apprendre cela, ce qui est vraisemblablement quelque chose de personnalisé, donc le fait d'avoir besoin d'écrire du code de gestion d'erreur personnalisé fait partie du paquet. Je suggérerais que vous composiez un format raisonnable que vous allez coller avec. Vous pouvez aller avec le meilleur de chaque monde et inclure plusieurs éléments d'information dans ce que vous revenez, peut-être le long de ces lignes:

[one of "ERROR" or "WARNING" or "MESSAGE"] 
[error code with no spaces, eg "BAD_MOVE"] 
[optional human readable string] 

De cette façon, si l'on a inventé un nouveau type d'erreur que les anciens clients ne comprennent pas, ils peuvent toujours reconnaître que le retour commence par "ERREUR" et savoir que quelque chose s'est mal passé; en analysant le code d'erreur (n'utilisez pas d'entiers, c'est une perte de temps pour tout le monde), ils peuvent prendre les mesures appropriées si c'est une erreur que le programmeur a prise en compte. Enfin, si vous mettez une chaîne conviviale pour les erreurs sélectionnées, il est facile de présenter quelque chose de gentil à l'utilisateur ou d'être utile pour le débogage.