Routing and routers
Keep routing explicit and boring: one clear ownership point for URL patterns, HTTP methods, and handler wiring.
Canonical guidance
- keep route wiring explicit
- make method rules obvious
- start with the standard library unless a real gap appears
Use when
- wiring HTTP services
- reviewing route organization
- deciding whether a router dependency is justified
Avoid
- handler-local route registration
- hidden method checks buried deep in handlers
- router abstraction layers that obscure URL ownership
Preferred pattern
- one construction function registers routes and returns the configured handler tree
Anti-pattern
- scattering route setup across many packages with no single route inventory
Explanation: This is tempting in growing services, but it makes URL behavior harder to discover, test, and change safely.
Why
- routing is mostly about ownership and discoverability
Related pages
Sources
- net/http package - Go Team