Code de statut HTTP

Un code de statut HTTP est la réponse courte du serveur à une requête. Le premier chiffre indique la classe : 1xx information, 2xx succès, 3xx redirection, 4xx erreur client (la requête était incorrecte) et 5xx erreur serveur (la requête était peut-être correcte, mais le serveur a échoué). Vérifier le code de statut exact est généralement la première assertion de tout test d’API.

Les codes les plus utilisés par les testeurs

Code	Signification	Usage typique
200 OK	Succès avec un corps	GET, ou une mise à jour qui renvoie la ressource
201 Created	Une ressource a été créée	POST, avec un en-tête Location
204 No Content	Succès, sans corps	DELETE, certains PUT
301 / 302 / 304	Déplacé, trouvé ailleurs, non modifié	Redirections et cache
400 Bad Request	Requête mal formée ou invalide	JSON cassé, mauvais types
401 Unauthorized	Non authentifié	Token absent, expiré ou invalide
403 Forbidden	Authentifié mais non autorisé	Utilisateur valide, mauvais rôle
404 Not Found	Ressource inexistante	Id inconnu, ou masquage d’une ressource interdite
409 Conflict	Conflit avec l’état actuel	E-mail en double, conflit de version
422 Unprocessable Content	Bien formée mais échoue à la validation	Violations de règles métier
429 Too Many Requests	Limite de débit dépassée	Souvent avec Retry-After
500 / 502 / 503 / 504	Erreur serveur, mauvaise passerelle, indisponible, timeout de passerelle	Bugs et infrastructure

401 ou 403

Malgré son nom, 401 Unauthorized concerne l’authentification : le serveur ne sait pas qui vous êtes. La solution est de se connecter ou d’envoyer un token valide, et la réponse doit inclure un en-tête WWW-Authenticate. 403 Forbidden concerne l’autorisation : le serveur sait qui vous êtes et vous n’avez pas le droit de faire cette action. Se reconnecter n’y changera rien. Une suite de tests doit couvrir les deux : pas de token, un token expiré, et un token valide pour un utilisateur sans la bonne permission.

Erreurs courantes

• Ne vérifier que le 200. La plupart des défauts se trouvent dans les chemins d’erreur. Une entrée invalide doit obtenir un 4xx ; un 500 signifie une entrée non gérée et mérite un rapport de bug.
• Des erreurs avec un statut 200. Un message d’erreur dans un corps 200 casse les clients et la supervision.
• Des conventions incohérentes. Certaines API utilisent 400 pour toute entrée incorrecte, d’autres réservent 422 aux échecs de validation. Les deux se valent ; c’est le mélange des deux au sein d’une même API qui constitue le bug.