How do you decide whether http.ServeMux is enough to replace a service's third-party router, and who owns that call?

## Why this is a real decision and not a style argument Until Go 1.22 the standard mux matched path prefixes only: no methods, no path variables. Every service with a REST-shaped API therefore either hand-rolled dispatch or took a routing dependency, and taking one was the obvious call. Go 1.22 changed the premise, so services carrying a router now carry it by inertia rather than by necessity — and inertia is exactly the kind of thing a lead is expected to periodically re-examine and, often, to leave alone. ## Step one: inventory, from the code and not from memory Enumerate every routing feature the service actually uses. The standard `ServeMux` covers: - method-constrained patterns, with GET also serving HEAD; - `{name}` single-segment and `{name...}` trailing wildcards, read back by name; - host-qualified patterns; - subtree patterns via a trailing slash, plus `{$}` to anchor an exact path; - overlap resolution by specificity, with conflicting pairs rejected at registration; - 405 with an `Allow` header when a path exists under other methods. What it does not offer, and what you must therefore find in your code: constraints on the *shape* of a path segment (numeric-only, a regular expression), route grouping with shared configuration attached to a subtree, route-level hooks, and any behaviour that depends on ordered first-match evaluation. Also count the places that read routing metadata the standard library exposes differently. If that list comes back empty, the case for migrating is a dependency you no longer patch, upgrade or vet, and a routing model a new hire already knows from the standard library. If it comes back with three entries you would have to reimplement, migrating means writing and owning routing code, which is strictly worse than importing it. ## Step two: price the risk, which is behavioural, not mechanical The patterns look similar enough to invite a find-and-replace, and that is the trap. Two semantic differences bite: 1. **Precedence.** Many routers evaluate routes in registration order and take the first match. `ServeMux` compares patterns and takes the most specific one, regardless of order. A port therefore changes which handler serves overlapping paths, and it does so without any error, because a narrower pattern beating a broader one is legal and silent. 2. **Trailing slashes.** A trailing slash makes a pattern a subtree, and a request for the slash-less root gets a redirect rather than a direct match. That converts one request into two and, on older toolchains, can rewrite a POST into a GET. The mitigation is a sequencing rule: write the route-behaviour test **against the existing router first**, so it encodes today's production behaviour rather than tomorrow's intention, then swap the implementation and require the same table to stay green. Any row that has to change during the swap is a deliberate behaviour change that belongs in the pull-request description and, if it touches a public URL, in a release note. ## Step three: the constraints you do not own - **Toolchain floor.** The pattern syntax needs Go 1.22 or later; the subtree redirect is 307 rather than 301 only from Go 1.26. If the fleet's minimum is older, the toolchain upgrade is the real project and routing is a rider on it. Pin the floor in `go.mod` and say why. - **Platform standards.** If a platform or infrastructure group has standardised the stack — a shared service template, a common set of libraries, a security review keyed to specific dependencies — then a service diverging in either direction has a cost the service team does not pay. That group can overrule you, and the correct posture is to bring the inventory and the test plan as a proposal rather than to land the change and defend it afterwards. - **Opportunity cost.** Routing churn is invisible to users. In a quarter with a reliability or delivery goal, a migration with no user-visible benefit is the wrong use of the change budget, however sound the technical argument. "Correct, and not now" is a complete answer. ## Step four: sequence it so it is reversible Put all registrations behind one constructor returning the assembled handler. That single seam makes the swap a one-file change, keeps the test pointed at the real thing, and makes reverting a revert rather than an archaeology exercise. Land the test, land the constructor, then land the swap as its own commit. ## What a strong answer sounds like It names the specific capabilities on both sides rather than arguing "fewer dependencies is better", it identifies the silent-reroute risk and the test that removes it, it states the toolchain floor as a hard constraint, and it is explicit about who decides: the service's lead proposes and owns the outcome, the platform group can veto on standardisation grounds, and the honest answer is sometimes to leave a working router alone.