Construir un servidor HTTP robusto en Go requiere algo más que mapear rutas a handlers. Cuando tu aplicación crece —como una tienda en línea que valida autenticación, inventario y métodos de pago— necesitas encadenar middlewares y distinguir entre métodos HTTP para cada ruta. Aquí se explica cómo lograrlo paso a paso, transformando un router básico en uno capaz de soportar un REST API completo.
¿Por qué encapsular lógica en middlewares?
Imagina que estás procesando pedidos en una tienda en línea [0:08]. Primero verificas que el usuario esté autenticado, luego que haya suficiente inventario y después que el método de pago funcione. Si colocas toda esa lógica dentro de un solo handler, terminas con código difícil de mantener y de reutilizar.
La solución es encapsular cada validación en un middleware independiente [1:00]. De esta forma:
- Cada middleware cumple una sola responsabilidad.
- Si alguna validación falla, se devuelve un error claro al usuario.
- Puedes reutilizar middlewares en distintos endpoints sin reescribir código.
Por ejemplo, la validación de inventario que usas al crear una orden es exactamente la misma que necesitas cuando alguien agrega un producto a su carrito de compra [1:22]. Simplemente agregas ese middleware a la cadena y listo.
¿Cómo asociar métodos HTTP con rutas usando mapas de mapas?
Hasta este punto, el router mapeaba únicamente strings (rutas) a handlers. Cuando envías un POST a /api, el servidor respondía igual que con un GET porque solo evaluaba la URL, no el método [2:22].
Para resolverlo, se transforma la estructura del router en un mapa de mapas [3:06]. La idea es mapear primero del verbo HTTP a la ruta y luego de la ruta al handler:
go
rules map[string]map[string]http.HandlerFunc
Esto significa que la primera llave es el método (POST, GET, PUT, DELETE) y la segunda llave es el path (/api). Con una sola llamada a make, Go inicializa toda la estructura sin necesidad de invocar make dos veces [3:52].
¿Qué cambia en la función find handler?
La función que busca handlers ahora recibe dos parámetros: el path y el método [4:28]. Además, devuelve tres valores: el handler, un booleano que indica si el método existe y otro booleano para saber si la ruta existe.
go
func (r *Router) findHandler(path string, method string) (http.HandlerFunc, bool, bool)
Esta doble verificación es fundamental. Si la ruta /api existe pero solo para POST, y el cliente envía un GET, el servidor responde con 405 Method Not Allowed en lugar de un genérico 404 [5:48]. Así el cliente sabe que la URL es correcta, pero debe usar otro verbo.
¿Cómo se obtiene el método del request?
El objeto request en Go contiene toda la información necesaria. Basta con acceder a r.Method para saber si se trata de un GET, POST, PUT o DELETE [5:16]. Este valor se pasa directamente a findHandler para determinar qué handler ejecutar.
¿Cómo evitar el error de mapa nulo al registrar rutas?
Al ejecutar el servidor por primera vez con la nueva estructura, aparece un panic por mapa nulo [7:06]. Esto ocurre porque al registrar una ruta, el código asume que ya existe el mapa interno para ese path, pero todavía no se ha creado.
La solución es verificar si el mapa interno existe antes de asignar [7:38]:
go
if _, exists := s.rules[path]; !exists {
s.rules[path] = make(map[string]http.HandlerFunc)
}
Se evalúa con la negación del booleano: si no existe, se crea con make. Después se asigna el handler al método correspondiente dentro de ese mapa.
Con esta corrección, al probar en Postman [8:22]:
- Un
GET a /api devuelve 405 Method Not Allowed.
- Un
POST a /api responde correctamente.
Esto confirma que el router ahora asocia URLs con métodos HTTP de forma precisa [8:44]. La combinación de ruta y verbo determina qué handler se ejecuta, lo que permite implementar un REST API donde:
GET lee recursos.POST crea nuevos.PUT actualiza existentes.DELETE los elimina.
Antes, cualquier método entraba al mismo handler porque solo se evaluaba la URL. Ahora, con mapas de mapas y la validación del método, el servidor responde de forma diferenciada y profesional. Si tienes dudas sobre cómo extender esta lógica o agregar más middlewares a tu cadena, compártelas en los comentarios.
