Dans le domaine du développement Web Go, afin d'atteindre des fonctions de routage plus efficaces et flexibles, de nombreux développeurs choisissent d'introduire des bibliothèques de troisième partie telles que HTTPRURTER et GORILLA / MUX. Cependant, dans la version Go 1.22, l'optimisation officielle du HTTP.Servermux dans la bibliothèque standard devrait réduire la dépendance des développeurs qui s'appuient sur les bibliothèques d'itinéraires de troisième partie.
GO 1.22 La version a réalisé la proposition très attendue et a amélioré la capacité de correspondance du mode Multi-Road Multi-Road Mode par défaut par défaut dans le package standard de bibliothèque NET / HTTP. La réutilisation multi-voies existante (HTTP.Servermux) ne peut fournir que des fonctions de correspondance de chemin de base, ce qui est relativement limité, ce qui entraîne un grand nombre de bibliothèques de troisième partie pour répondre aux besoins des développeurs pour des fonctions d'itinéraire plus fortes. Le nouveau réarrêt multi-voies dans GO 1.22 réduira considérablement l'écart de fonction avec la bibliothèque de troisième partie en introduisant des capacités de correspondance avancées. Cet article présentera brièvement la nouvelle réutilisation multi-voies (MUX), qui fournit un exemple de serveur de repos, et compare les performances de la nouvelle bibliothèque standard MUX et Gorilla / MUX.
Pour les développeurs GO avec un troisième mXX / routeur (comme le gorille / mux), l'utilisation de nouveaux mXX standard sera une chose simple et familière. Il est recommandé que les développeurs lisent d'abord leurs documents officiels, ce qui est simple et clair.
Le code suivant montre quelques nouvelles fonctions de correspondance de mode de Mux:
<code class="language-go">package main import ( "fmt" "net/http" ) func main() { mux := http.NewServeMux() mux.HandleFunc("GET /path/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "got path\n") }) mux.HandleFunc("/task/{id}/", func(w http.ResponseWriter, r *http.Request) { id := r.PathValue("id") fmt.Fprintf(w, "handling task with %s\n", id) }) http.ListenAndServe(":8090", mux) }</code>
Le programmeur GO expérimenté peut immédiatement remarquer deux nouvelles fonctionnalités:
/path/
, et que la demande d'autres méthodes HTTP ne sera pas traitée. {id}
contient le format, qui n'est pas pris en charge dans la version précédente. Cette réussite peut correspondre à un seul composant de chemin et le programme de traitement peut obtenir la valeur de correspondance via la méthode PathValue
demandée. Ce qui suit est un exemple d'utilisation de la commande curl pour tester ce serveur:
<code class="language-bash">$ gotip run sample.go # 在另一个终端测试 $ curl localhost:8090/what/ 404 page not found $ curl localhost:8090/path/ got path $ curl -X POST localhost:8090/path/ Method Not Allowed $ curl localhost:8090/task/leapcell/ handling task with leapcell</code>
À partir des résultats du test, on peut voir que le serveur refuse de demander le post /path/
, permet uniquement aux demandes de GET (Curl par défaut d'utiliser les demandes de Get). Dans le même temps, lorsque la demande correspond, le pas id
recevra la valeur correspondante. Il est recommandé que les développeurs se réfèrent en détail à la nouvelle documentation Servemux pour apprendre plus de fonctions, telles que le chemin de queue et les règles de correspondance de mixage {id}
, et la correspondance stricte du chemin de {$}
.
La proposition accorde une attention particulière au conflit entre différents modèles. Ce qui suit est un exemple:
<code class="language-go">mux := http.NewServeMux() mux.HandleFunc("/task/{id}/status/", func(w http.ResponseWriter, r *http.Request) { id := r.PathValue("id") fmt.Fprintf(w, "handling task status with %s\n", id) }) mux.HandleFunc("/task/0/{action}/", func(w http.ResponseWriter, r *http.Request) { action := r.PathValue("action") fmt.Fprintf(w, "handling task action with %s\n", action) })</code>
Lorsque le serveur reçoit une demande à /task/0/status/
, les deux procédures de traitement peuvent correspondre à cette demande. Le nouveau document Servemux décrit les règles de priorité du modèle et comment gérer les conflits potentiels. Si un conflit se produit, le processus d'enregistrement déclenchera la panique. Pour l'exemple ci-dessus, les messages d'erreur suivants apparaîtront:
<code class="language-go">package main import ( "fmt" "net/http" ) func main() { mux := http.NewServeMux() mux.HandleFunc("GET /path/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "got path\n") }) mux.HandleFunc("/task/{id}/", func(w http.ResponseWriter, r *http.Request) { id := r.PathValue("id") fmt.Fprintf(w, "handling task with %s\n", id) }) http.ListenAndServe(":8090", mux) }</code>
Ce message d'erreur est détaillé et pratique. Dans les scénarios d'enregistrement complexes (en particulier lors de l'inscription dans plusieurs positions du code source), ces détails peuvent aider les développeurs à localiser et à résoudre rapidement des problèmes de conflit.
La série de serveurs Rest dans GO utilise une variété de méthodes pour implémenter un serveur simple dans la tâche / à appliquer dans GO. La première partie est basée sur la bibliothèque standard, et la deuxième partie utilise le routeur Gorilla / MUX pour réintégrer le même serveur. Désormais, l'utilisation du MAX amélioré GO 1.22 pour implémenter à nouveau ce serveur est d'une grande importance, et il est également intéressant de le comparer avec des solutions à l'aide de Gorilla / Mux.
Ce qui suit fait partie du code d'enregistrement du mode représentatif:
<code class="language-bash">$ gotip run sample.go # 在另一个终端测试 $ curl localhost:8090/what/ 404 page not found $ curl localhost:8090/path/ got path $ curl -X POST localhost:8090/path/ Method Not Allowed $ curl localhost:8090/task/leapcell/ handling task with leapcell</code>
Semblable aux exemples de gorille / mux, voici un routage de demande vers différentes procédures de traitement avec le même chemin avec une méthode HTTP spécifique. Lorsque vous utilisez l'ancien HTTP.Servermux, ce type de dispositif de correspondance dirigera la demande au même programme de traitement, puis le programme de traitement déterminera l'opération de suivi en fonction de la méthode de la demande.
Ce qui suit est un exemple de programme de traitement:
<code class="language-go">mux := http.NewServeMux() mux.HandleFunc("/task/{id}/status/", func(w http.ResponseWriter, r *http.Request) { id := r.PathValue("id") fmt.Fprintf(w, "handling task status with %s\n", id) }) mux.HandleFunc("/task/0/{action}/", func(w http.ResponseWriter, r *http.Request) { action := r.PathValue("action") fmt.Fprintf(w, "handling task action with %s\n", action) })</code>
Ici, le processus est extrait de req.PathValue("id")
pour extraire la valeur d'ID, ce qui est similaire à la méthode du gorille. Cependant, comme le {id}
ne correspond qu'à l'entier avec une expression régulière, il est nécessaire de faire attention à l'erreur de strconv.Atoi
retourné.
En général, le résultat final est très similaire à une solution utilisant du gorille / mux. Par rapport à la méthode traditionnelle de la bibliothèque standard, le nouveau MUX peut effectuer des opérations de routage plus compliquées, en réduisant les besoins de laisser la décision de routage au programme de traitement lui-même et d'améliorer l'efficacité du développement et la maintenance du code.
Bien sûr, certains développeurs continueront de choisir des bibliothèques de tiers familières, ce qui est également raisonnable. Les routeurs comme Gorilla / Mux ont encore plus de fonctions que les bibliothèques standard. De plus, de nombreux programmeurs GO choisissent des cadres légers tels que le gin car il fournit non seulement des routeurs, mais fournit également des outils d'appel d'offres nécessaires pour créer un back-end.
En bref, l'optimisation de l'optimisation de la bibliothèque standard GO 1.22 http.serv est sans aucun doute un changement positif. Que les développeurs choisissent d'utiliser un package de troisième partie ou d'insister sur l'utilisation de la bibliothèque standard, la fonction de l'amélioration de la bibliothèque standard est bénéfique pour l'ensemble de la communauté de développement GO.
Enfin, je recommande une plateforme la plus adaptée au déploiement des services Go : Leapcell
Twitter de Leapcell : https://www.php.cn/link/7884effb9452a6d7a7a79499ef854afd
(Remarque : j'ai conservé les balises d'image en raison de l'impossibilité d'accéder au lien de l'image, veuillez vous assurer que le chemin de l'image est correct.)
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!