Erreur commune : gérer une réponse d'API avec un code d'erreur

Pourquoi un code robuste ne peut pas ignorer les erreurs ?

Un développeur optimiste suppose que chaque requête API renverra un beau code de statut 200 OK avec les données attendues. Un développeur professionnel, lui, sait que les choses peuvent mal tourner. Le réseau peut être instable, la ressource demandée peut ne pas exister, ou le serveur de l'API peut rencontrer un problème. Ignorer ces possibilités est la recette pour une application fragile qui plantera de manière inattendue.

Considérez ce code naïf :

require 'httparty'

# On demande un post qui n'existe pas
response = HTTParty.get('https://jsonplaceholder.typicode.com/posts/99999')

# On essaie d'accéder au titre sans vérifier si la requête a réussi
puts response.parsed_response['title'] # => ERREUR !

Ce code va planter avec une erreur NoMethodError, car si le post 99999 n'existe pas, l'API renvoie un code 404 Not Found. Le corps de la réponse sera un objet JSON simple comme {}, et response.parsed_response sera un Hash vide. Tenter d'accéder à la clé 'title' sur un Hash vide retourne nil, et appeler une méthode sur nil provoque un crash. La gestion des codes d'erreur n'est donc pas une option, c'est une nécessité.

La première ligne de défense : vérifier le code de statut

Comme nous l'avons esquissé dans les exemples précédents, la première et la plus importante des vérifications à faire après chaque requête est celle du code de statut HTTP. L'objet réponse de HTTParty nous le rend facilement accessible via la méthode .code.

La pratique la plus sûre est d'encapsuler le traitement de la réponse dans une condition qui ne s'exécute que si la requête a été un succès. Les codes de succès sont ceux de la famille 2xx (200, 201, 204, etc.).

require 'httparty'

response = HTTParty.get('https://jsonplaceholder.typicode.com/posts/99999')

# On ne traite la réponse que si le code est 200
if response.code == 200
  post_data = response.parsed_response
  puts "Titre du post : #{post_data['title']}"
else
  # Sinon, on affiche un message d'erreur clair
  puts "La requête a échoué. L'API a répondu avec le code de statut : #{response.code}."
  puts "Corps de la réponse : #{response.body}"
end

Ce code est déjà beaucoup plus robuste. Il ne plantera jamais. Si le post n'existe pas, il entrera dans la branche else et affichera un message informatif, permettant au développeur (ou à l'utilisateur) de comprendre ce qui s'est passé.

Gérer différents types d'erreurs avec une structure `case`

Pour un contrôle encore plus fin, vous pouvez vouloir que votre application réagisse différemment selon le type d'erreur. Par exemple, une erreur 404 Not Found n'est pas la même chose qu'une erreur 401 Unauthorized (clé API invalide) ou une erreur 500 Internal Server Error (problème côté serveur).

Une structure case est parfaite pour gérer ces différents scénarios de manière lisible.

require 'httparty'

# Testons avec une URL qui n'existe pas sur le domaine
response = HTTParty.get('https://api.github.com/non-existent-endpoint')

case response.code
when 200..299
  puts "Succès ! Traitement des données..."
  puts response.parsed_response
when 404
  puts "Erreur : La ressource demandée n'a pas été trouvée (404 Not Found)."
  puts "Vérifiez l'URL de l'endpoint."
when 401
  puts "Erreur : Accès non autorisé (401 Unauthorized)."
  puts "Vérifiez que votre clé d'API est valide."
when 500..599
  puts "Erreur serveur (#{response.code}). L'API rencontre des difficultés."
  puts "Veuillez réessayer plus tard."
else
  puts "Erreur inattendue avec le code de statut : #{response.code}."
end

Cette approche rend votre application beaucoup plus intelligente et capable de fournir un retour utile à l'utilisateur ou de déclencher des actions appropriées, comme une nouvelle tentative après une erreur serveur.

Conseil pro : utiliser les méthodes d'aide de HTTParty

HTTParty fournit des méthodes booléennes pratiques sur l'objet réponse pour rendre les vérifications encore plus expressives et lisibles, au lieu de comparer manuellement des plages de codes.

• response.success? : Retourne true si le code de statut est dans la plage 2xx.
• response.not_found? : Retourne true si le code est 404.
• response.unauthorized? : Retourne true si le code est 401.
• response.server_error? : Retourne true si le code est dans la plage 5xx.

Réécrivons notre premier exemple de manière plus idiomatique avec .success? :

require 'httparty'

response = HTTParty.get('https://jsonplaceholder.typicode.com/posts/99999')

if response.success?
  puts "Titre : #{response.parsed_response['title']}"
else
  puts "La requête a échoué. Code: #{response.code}."
end

Ce code est non seulement plus court, mais il exprime aussi plus clairement son intention. Adopter ces méthodes d'aide est une bonne pratique qui améliorera la qualité et la lisibilité de votre code d'interaction avec les API.