집 >백엔드 개발 >Golang >go &#s http.servemux 만 있으면됩니다

go &#s http.servemux 만 있으면됩니다

Mary-Kate Olsen원래의: 2025-01-27 22:07:10951검색

표준 라이브러리에서 http.servemux의 최적화 및 애플리케이션 분석 GO 웹 개발 분야에서보다 효율적이고 유연한 라우팅 기능을 달성하기 위해 많은 개발자들이 HTTProuter 및 Gorilla/MUX와 같은 세 번째 파티 라이브러리를 소개하기로 선택했습니다. 그러나 GO 1.22 버전에서 표준 라이브러리에서 HTTP.Servemux의 공식 최적화는 개발자가 제 3 자 경로 라이브러리에 의존하는 의존성을 줄일 것으로 예상됩니다.

1. Go 1.22 하이라이트 : 향상된 모드 매칭 능력

GO 1.22 버전은 매우 기대되는 제안을 실현하고 표준 라이브러리 NET/HTTP 패키지의 기본 HTTP 서비스 멀티로드 컴플라이케이터 모드 일치 기능을 향상 시켰습니다. 기존의 다중 웨이 재사용 (http.servemux)은 기본 경로 일치 함수 만 제공 할 수 있으며, 이는 상대적으로 제한되어있어 더 강력한 경로 기능을 위해 개발자의 요구를 충족시키기 위해 많은 수의 제 3 자 라이브러리가 생성됩니다. GO 1.22의 새로운 다중 웨이 액치는 고급 일치 기능을 도입하여 제 3 자 라이브러리의 기능 간격을 크게 줄입니다. 이 기사는 REST 서버 예제를 제공하는 새로운 다중 중장 재사용 (MUX)을 간략하게 소개하고 새로운 표준 라이브러리 MUX 및 Gorilla/MUX의 성능을 비교합니다.

2. 새 mux

를 사용하는 방법 세 번째 파티 MUX/라우터 (Gorilla/MUX)가있는 GO 개발자의 경우 새로운 표준 MUX를 사용하는 것이 간단하고 친숙한 것입니다. 개발자는 먼저 공식 문서를 읽는 것이 좋습니다. 이는 간단하고 명확합니다.

(1) 기본 사용 예 다음 코드는 MUX의 일부 새로운 모드 일치 함수를 보여줍니다 :

경험이 풍부한 GO 프로그래머는 즉시 두 가지 새로운 기능을 알 수 있습니다.

첫 번째 처리 프로그램에서 HTTP 방법 (이 예제에서 얻음)은 패턴의 일부로 명시 적으로 사용됩니다. 이는 여기서 처리 프로그램이

의 경로에 대한 GET 요청에만 응답하고 다른 HTTP 방법의 요청은 처리되지 않음을 의미합니다.

두 번째 처리 프로그램에서 두 번째 경로 구성 요소

에는 이전 버전에서 지원되지 않는 형식이 포함되어 있습니다. 이 패스는 단일 경로 구성 요소와 일치 할 수 있으며 처리 프로그램은 요청 된

메소드를 통해 일치하는 값을 얻을 수 있습니다.

다음은 CURL 명령을 사용 하여이 서버를 테스트하는 예입니다.

테스트 결과에서 서버가 게시물을 요청하지 않으면 get requests 만 허용합니다 (CURL 기본값이 Get requests를 사용하는 CURL 기본값). 동시에 요청 일치하면 피치에 해당 값이 부여됩니다. 개발자는 테일 경로 및 (2) 모드 충돌 처리

제안은 다른 모델 간의 갈등에 특별한주의를 기울입니다. 다음은 예입니다 :

<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>

서버가

에 요청을 받으면 두 처리 절차 모두이 요청과 일치 할 수 있습니다. 새로운 Servemux 문서는 패턴 우선 순위 규칙과 잠재적 충돌을 다루는 방법을 설명합니다. 충돌이 발생하면 등록 절차가 공황을 유발합니다. 위의 예에서는 다음 오류 메시지가 나타납니다.

<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>

이 오류 메시지는 자세하고 유용합니다. 복잡한 등록 시나리오(특히 스키마가 소스 코드의 여러 위치에 등록된 경우)에서 이러한 세부 정보는 개발자가 충돌을 신속하게 찾고 해결하는 데 도움이 될 수 있습니다.

3. 새로운 Mux를 사용하여 서버 구현

Go의 REST 서버 제품군은 다양한 방법을 사용하여 Go에서 작업/할 일 애플리케이션을 위한 간단한 서버를 구현합니다. 첫 번째 부분은 표준 라이브러리를 기반으로 구현되었으며, 두 번째 부분은 gorilla/mux 라우터를 사용하여 동일한 서버를 다시 구현합니다. 이제 Go 1.22 향상된 mux를 사용하여 이 서버를 다시 구현하는 것이 합리적이며 gorilla/mux를 사용하는 솔루션과 비교하는 것도 흥미로울 것입니다.

(1) 패턴 등록 예시

대표적인 패턴등록코드는 다음과 같습니다.

<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>

gorilla/mux 예시와 마찬가지로 여기서는 동일한 경로를 가진 요청을 다른 핸들러로 라우팅하기 위해 특정 HTTP 메서드가 사용됩니다. 이전 http.ServeMux를 사용할 때 이러한 매처는 요청을 동일한 핸들러로 보낸 다음 요청 메소드에 따라 다음에 수행할 작업을 결정합니다.

(2) 핸들러 예시

다음은 핸들러의 코드 예시입니다.

<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>

이 핸들러는 Gorilla 메서드와 유사하게 req.PathValue("id")에서 ID 값을 추출합니다. 그러나 {id}이 정수만 일치하도록 지정하기 위해 정규 표현식을 사용하는 것이 아니기 때문에 strconv.Atoi에서 반환되는 오류에 주의해야 합니다.

전반적으로 최종 결과는 gorilla/mux를 사용한 솔루션과 매우 유사합니다. 기존 표준 라이브러리 방법과 비교하여 새로운 Mux는 더 복잡한 라우팅 작업을 수행할 수 있으므로 라우팅 결정을 핸들러 자체에 맡길 필요성이 줄어들고 개발 효율성과 코드 유지 관리성이 향상됩니다.

4. 결론

“어떤 라우팅 라이브러리를 선택해야 할까요?”는 Go 초보자들이 늘 겪는 공통적인 질문이었습니다. 이 질문에 대한 답변은 Go 1.22가 출시된 후에 변경될 수 있습니다. 많은 개발자는 새로운 표준 라이브러리 Mux가 자신의 요구 사항에 충분하므로 타사 패키지에 의존할 필요가 없다는 사실을 알게 될 것입니다.

물론 일부 개발자는 친숙한 타사 라이브러리를 계속 선택하므로 이는 합리적입니다. Gorilla/mux와 같은 라우터에는 여전히 표준 라이브러리보다 더 많은 기능이 있습니다. 또한 많은 Go 프로그래머는 Gin과 같은 경량 프레임워크를 선택할 것입니다. Gin은 라우터를 제공할 뿐만 아니라 웹 백엔드를 구축하는 데 필요한 추가 도구도 제공하기 때문입니다.

요컨대 Go 1.22에서 표준 라이브러리 http.ServeMux의 최적화는 의심할 여지 없이 긍정적인 변화입니다. 개발자가 타사 패키지를 사용하든 표준 라이브러리를 사용하든 관계없이 표준 라이브러리의 기능을 향상하면 전체 Go 개발 커뮤니티에 도움이 됩니다.