Writing HTTP services in Go: is the standard library enough?

One rule I set for myself while learning Go was this: I wouldn’t pull in an external library until I’d tried to build the thing with the standard library first. That rule was occasionally frustrating, but it taught me a lot — it followed directly from the intent I described in why I started learning Go: to get to know the language itself rather than through its tooling. HTTP services turned out to be the area that really put it to the test.

In PHP, some framework is always running underneath everything — Laravel, Slim, whatever. Writing an HTTP server in raw PHP is theoretically possible, but nobody does it. In Go, on the other hand, the net/http package is genuinely usable; production services get written with the standard library every day. That difference forces a shift in mindset.

A basic server with net/http

Getting a Go HTTP server running takes just a few lines:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        fmt.Fprintln(w, `{"status":"ok"}`)
    })

    http.ListenAndServe(":8080", nil)
}

It runs, responds on port 8080, zero dependencies. That simplicity feels satisfying at first — but as soon as you start building a real API, the limitations surface.

What the standard library is missing

The HandleFunc-based registration mechanism in net/http isn’t flexible enough. Route parameters — dynamic path segments like /users/123 — did not exist in the standard library at the time I wrote this. You had to parse them by hand:

http.HandleFunc("/users/", func(w http.ResponseWriter, r *http.Request) {
    // manually extract everything after "/users/"
    id := r.URL.Path[len("/users/"):]
    if id == "" {
        // return list
        return
    }
    // return single record
})

This approach is tolerable for two or three routes, but it becomes unmanageable at ten. HTTP method dispatch (GET/POST/PUT/DELETE) also has to be done by hand:

switch r.Method {
case http.MethodGet:
    // handle GET
case http.MethodPost:
    // handle POST
default:
    http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
}

Copy-pasting that switch block into every handler inflates the code quickly. The standard library doesn’t abstract this common pattern away — you either write it yourself or delegate it to a library.

A note from today: this gap has since closed. Go 1.22 added enhanced routing patterns to net/http’s ServeMux — wildcards like /items/{id} are now recognised by the standard library and the matched segment is read with Request.PathValue; registering a handler as "POST /items/create" restricts it to that method. So the hand-rolled parsing and the switch r.Method block above have not been necessary since 2024. The reasoning in the rest of this post — when to reach for a library — still holds; what moved is where the threshold sits.

Where is the framework threshold?

Before reaching for a library, I ask myself: how generic is the need that the standard library isn’t covering? Route parameters and HTTP method routing are generic and universal — every service needs them.

That’s when I look at third-party packages. In the Go ecosystem, gorilla/mux and chi are lightweight routers that fill this gap. They’re not frameworks; they simply add route parameters and method matching on top of net/http, and they conform to the standard http.Handler interface.

import "github.com/go-chi/chi"

r := chi.NewRouter()

r.Get("/users/{id}", func(w http.ResponseWriter, req *http.Request) {
    id := chi.URLParam(req, "id")
    // work with id
})

http.ListenAndServe(":8080", r)

The core philosophy is preserved: a plugin that conforms to the standard library’s interfaces and doesn’t conflict with other packages. Not a large dependency pile like Laravel.

What convinced me about chi is its full compliance with the standard http.Handler interface — its own README claims it is “100% compatible with net/http” with “no external dependencies — plain ol’ Go stdlib + net/http”. When evaluating a library, I pay close attention to this; a router that breaks the standard interface makes it harder to work with middleware or utilities that expect it. A handler written with chi can be used with any other net/http-compatible setup.

JSON responses and error handling

The standard library ships encoding/json for serialization, and it works well:

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

func writeJSON(w http.ResponseWriter, status int, data interface{}) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(status)
    json.NewEncoder(w).Encode(data)
}

This small helper eliminates repetition; all handlers use it.

Comparison with PHP

Writing an HTTP service in Go is different from writing one in PHP without a framework: the standard library is genuinely production-ready, well-maintained, and fast. But the layers Laravel provides — authentication, ORM, queues, email — aren’t present in Go, nor do they need to be. Go services typically do one narrower responsibility very well; broader concerns bring in other languages.

---

The bottom line: Go’s standard library covers a great deal, but not everything. Reaching for a lightweight library for route parameters and method routing is a reasonable trade-off. Jumping to a full framework is a premature decision in most cases — something you can do when the need genuinely grows to that scale.

---

Sources

• Go 1.22 Release Notes: Enhanced routing patterns
• Go Packages: net/http
• Go Packages: encoding/json
• go-chi/chi