Handling JSON Post Request en Go : pourquoi même les développeurs expérimentés tombent dans les pièges
\n\nAvez-vous déjà écrit un serveur en Go qui doit accepter du JSON via une requête POST, et soudainement obtenu une structure vide ou une erreur fatale ? Si oui, vous n'êtes pas seul. La question "Handling JSON Post Request in Go" sur Stack Overflow a rassemblé des dizaines de milliers de vues et des centaines de réponses. C'est un véritable "point sensible" de la communauté.
\n\nDans cet article, nous ne nous contenterons pas d'expliquer comment traiter correctement les requêtes POST JSON. Nous passerons en revue les pièges les plus courants dans lesquels tombent les débutants et même les professionnels. Vous apprendrez à éviter les erreurs typiques, à écrire un code propre et à ne pas perdre des heures en débogage. C'est parti !
\n\nPourquoi JSON et Go sont-ils un amour dès le premier octet ?
\n\nGo (ou Golang) a été créé pour les services web modernes. Le package intégré encoding/json est un outil puissant. Mais, comme tout outil puissant, il nécessite une manipulation correcte. Le problème le plus fréquent est l'inadéquation entre le JSON envoyé par le client et la structure attendue par le serveur.
Commençons par les bases — la structure correcte du gestionnaire.
\n\nErreur n°1 : Oublier de fermer le corps de la requête
\n\nLa première chose à faire dans tout gestionnaire POST est de fermer impérativement le corps de la requête. Ce n'est pas seulement une bonne pratique, c'est une garantie que votre serveur ne fuira pas de mémoire.
\n\npackage main\n\nimport (\n "encoding/json"\n "net/http"\n)\n\ntype User struct {\n Name string `json:"name"`\n Email string `json:"email"`\n}\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n // IMPORTANT : fermer le Body\n defer r.Body.Close()\n\n // ... reste du code\n}\n\nDe nombreux débutants sautent cette ligne, et le serveur commence à "consommer" de la mémoire. Utilisez toujours defer r.Body.Close() immédiatement après avoir reçu la requête.
Erreur n°2 : Ignorer la vérification de la méthode de la requête
\n\nVotre gestionnaire doit explicitement vérifier qu'il s'agit bien d'une requête POST, et non GET ou PUT. Sinon, vous risquez une panique ou un comportement étrange.
\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n defer r.Body.Close()\n\n if r.Method != http.MethodPost {\n http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)\n return\n }\n\n // ... ensuite on travaille avec le JSON\n}\n\nCette règle simple vous évitera bien des maux de tête. Vérifiez toujours la méthode — c'est l'hygiène de base du code.
\n\nErreur n°3 : Utiliser un décodeur JSON non strict
\n\nPar défaut, json.Decoder en Go ne génère pas d'erreur si le JSON contient des champs supplémentaires non décrits dans votre structure. Cela peut vous amener à "avaler" des données non valides.
La solution de secours consiste à utiliser json.Decoder avec l'option DisallowUnknownFields :
func handler(w http.ResponseWriter, r *http.Request) {\n defer r.Body.Close()\n\n var user User\n\n decoder := json.NewDecoder(r.Body)\n // Activation du mode strict\n decoder.DisallowUnknownFields()\n\n err := decoder.Decode(&user)\n if err != nil {\n http.Error(w, "Invalid JSON: "+err.Error(), http.StatusBadRequest)\n return\n }\n\n // Si le JSON contenait des champs supplémentaires — nous obtenons une erreur\n // C'est une protection contre les fautes de frappe accidentelles dans l'API\n\n w.WriteHeader(http.StatusOK)\n json.NewEncoder(w).Encode(user)\n}\n\nCette approche est particulièrement utile lorsque vous développez une API publique. Les clients vous remercieront pour des erreurs claires.
\n\nErreur n°4 : Ne pas vérifier que le JSON n'est pas vide
\n\nImaginez : le client envoie un corps de requête vide. Votre code décode sans problème le JSON vide {} et crée une structure avec des valeurs nulles. Cela peut ne pas correspondre à ce que vous attendez.
La meilleure pratique consiste à vérifier que le corps n'est pas vide et que tous les champs obligatoires sont remplis :
\n\nfunc hand