Routage de serveur HTTP amélioré dans Go 1.22

• Article sur l’amélioration des capacités de correspondance de motifs du multiplexeur HTTP de base servant les requêtes dans le package net/http de Go 1.22
• Le multiplexeur existant (http.ServeMux) fournissait une correspondance de chemins basique, ce qui imposait l’usage de bibliothèques tierces pour des fonctionnalités avancées
• Le nouveau multiplexeur de Go 1.22 offre une correspondance avancée, réduisant ainsi l’écart avec les packages tiers
• Le nouveau multiplexeur (mux) permet de spécifier explicitement les méthodes HTTP comme partie du motif et prend en charge la correspondance par jokers dans les composants du chemin
• L’article fournit des exemples d’utilisation du nouveau mux, y compris la gestion des conflits potentiels entre différents motifs
• La nouvelle documentation de ServeMux explique les règles de priorité pour les motifs et les conflits potentiels
• L’article revient aussi sur l’exemple d’une série consacrée aux serveurs REST en Go et compare l’apparence du nouveau mux de la stdlib à gorilla/mux
• Le nouveau mux de Go 1.22 permet un routage plus sophistiqué, ce qui réduit le besoin de prendre des décisions de routage à l’intérieur des handlers
• L’auteur estime que les améliorations de Go 1.22 vont changer la réponse habituelle à la question « quel package de routeur faut-il utiliser ? ». Beaucoup considéreront que le nouveau mux de la stdlib suffit à leurs besoins
• Cependant, certains programmeurs Go pourront toujours préférer des packages tiers ou des frameworks légers comme Gin. Ceux-ci fournissent le routeur ainsi que des outils supplémentaires pour construire des backends web
• Globalement, l’auteur voit les améliorations de Go 1.22 comme un changement positif pour tous les utilisateurs de Go, rendant la bibliothèque standard plus capable et bénéfique pour l’ensemble de la communauté

[GN⁺]

Avis Hacker News

• Un article sur le nouveau routage du serveur HTTP de Go 1.22.
• Des utilisateurs ont du mal à comprendre la panique qui se produit lorsque deux routes correspondent ; la plupart des frameworks web utilisent la première route enregistrée qui correspond.
• L’archivage puis la réactivation du projet gorrila/mux sèment la confusion, mais certains y voient une preuve de la résilience des projets open source.
• Critiques de la syntaxe proposée : certains suggèrent d’utiliser de vrais arguments au lieu de générer des chaînes « magiques » pour définir les handlers.
• Des utilisateurs n’aiment pas l’usage de préfixes de méthode sous forme de chaînes et préfèrent la sûreté de type de méthodes spécifiques au verbe HTTP.
• Des interrogations portent sur ce qui se passe lorsqu’une route correspond mais pas la méthode ; la réponse est un code 405 avec un en-tête Allow correctement renseigné.
• Il est suggéré que les utilisateurs ayant des besoins avancés ne devraient pas utiliser le sous-mux par défaut, mais envisager d’autres options ou écrire leur propre routeur.
• Certains préfèrent que les chemins qui se chevauchent soient résolus selon l’ordre de définition, plutôt que de provoquer une panique.
• Des utilisateurs n’aiment pas la proposition, en particulier l’inclusion de la méthode de requête HTTP dans l’URI.
• Critiques également envers le ServeMux par défaut, qui traite tout lorsqu’une adresse est un préfixe, sans moyen simple de gérer une correspondance exacte.
• Cependant, certains considèrent ce nouveau routage comme une évolution positive, qui réduit les dépendances externes et améliore la productivité.