Il est important d'être capable d'envoyer au client (le navigateur) si la requête à fonctionnée, plutôt qu'un rapport d'erreur HTML. Le but, au final est de pouvoir offrir à l'internaute un message lui indiquant si votre serveur est en train de mourir ou si le développeur est simplement incompétent.
Avec AJAX, on prend l'habitude de faire renvoyer par nos scripts du JSON. En cas d'erreur on fait quoi ? On envoie une clef
"error" avec un message d'erreur, et dans le pire des cas il est déjà traduit. Et si tout c'est bien passé et qu'il n'y a pas de donnée à retourner ? On envoie "true" ou "ok" en JSON.Bref, on réinvente la roue alors qu'il existe les codes de retours HTTP, et qu'il y en a plein. Exemples :
| 204 | No Content | Très pratique si il y'a rien a retourner. |
|---|---|---|
| 400 | Bad Request | Manque t-il quelques choses dans les paramètres ? |
| 403 | Forbidden | Il est temps de proposer une boite de login ! |
| 501 | Not Implemented | Fonctionnalité en cours de développement. |
Personnellement, je trouve ça fun de recevoir une requête AJAX, de renvoyer une 403 au client, que le javascript intercepte et affiche une boite d'authentification à l'internaute.
Surtout qu'avec les bibliothèques JavaScript d'aujourd'hui ça devient super simple. Exemple avec la fonction jQuery.getJSON().error().
Cela apporte un double avantage : le client javascript peut l’interpréter simplement et le développeur peut tester l'URL dans son navigateur et avoir un rapport intéressant. Si ce n'est pas assez fun, on peut également y ajouter les HTTP Status Cats.
Tout de même, il faut éviter de marcher sur les plates-bandes du serveur Web et éviter de renvoyer n'importe quoi.
La sémantique des codes de retour est aussi exploitée par les intermédiaires : les proxys savent qu'ils ne doivent pas pas cacher les 40x et 50x, les load balancers peuvent intercepter et redispatcher les 50x (sur les GET) dues aux serveurs defaillants ...). Et ces codes sont loggués par les serveurs.
Aucun commentaire:
Enregistrer un commentaire