En el Capitulo 1 construimos un servidor que respondia hello world a cada peticion. Eso es como tener una API que devuelve la misma respuesta tanto si el frontend llama a /api/users como a /api/products o /api/login. No muy util. En esta segunda entrega repensamos ese servidor para que sea consciente de las rutas, de modo que distintas rutas devuelvan distintas respuestas tal como en una API real.
Que ya tenemos hasta ahora Desde el Capitulo 1 contamos con un servidor basico que escucha en el puerto 3000, responde a peticiones HTTP y devuelve la misma respuesta para cualquier ruta. El problema que enfrentan los desarrolladores frontend es claro: cuando en el cliente se ejecuta algo como fetch a distintos endpoints se esperan datos diferentes para cada endpoint. Con el servidor actual siempre recibiriamos la misma respuesta.
Inspeccionando la ruta de la peticion La solucion empieza por mirar que es lo que el cliente pide. En Go eso se hace leyendo r.URL.Path dentro del metodo ServeHTTP. Si imprimimos el metodo y la ruta veremos entradas como GET /users o POST /api/login y a continuacion podemos devolver un mensaje que incluya la ruta solicitada para verificar que lo estamos leyendo correctamente. Por ejemplo al ejecutar en la terminal curl https://localhost:3000/users curl https://localhost:3000/products curl https://localhost:3000/api/login veremos respuestas que confirman la ruta solicitada.
Construyendo logica de rutas con switch Antes de saltar a una libreria de enrutamiento entendamos por que existen. La forma mas directa es usar una sentencia switch sobre la ruta y llamar a funciones manejadoras separadas. En ServeHTTP se obtiene path := r.URL.Path y se hace switch sobre path para despachar a funciones como hello, goodbye, getTime o welcome. Cada funcion escribira su propia respuesta en el ResponseWriter y asi mantenemos separadas las responsabilidades basicas.
Handlers sencillos Ejemplos de funciones manejadoras: welcome escribe un mensaje de bienvenida, hello escribe un saludo, goodbye escribe un mensaje de despedida y getTime obtiene la hora actual y la muestra. No olvides importar el paquete time para formatear la hora. Con esto al probar curl https://localhost:3000/hello curl https://localhost:3000/goodbye curl https://localhost:3000/time curl https://localhost:3000/ obtendremos respuestas distintas segun la ruta solicitada. Ahora nuestro servidor se comporta como una API simple.
Lo que hemos conseguido Resumen: en esta etapa tenemos enrutamiento basico por ruta, separacion limpia de handlers, manejo por defecto para rutas desconocidas y registro de peticiones para ver que se esta pidiendo al servidor.
Problemas que estamos creando Aunque el enfoque por switch funciona, aparece una serie de limitaciones que se vuelven dolorosas al escalar la aplicacion.
1. Ceguera ante el metodo HTTP El servidor no distingue entre metodos HTTP. Si haces curl -X POST https://localhost:3000/hello o curl -X DELETE https://localhost:3000/hello todas las llamadas obtendran la misma respuesta. En una API real GET /users y POST /users deben comportarse de forma muy diferente.
2. Sentencia switch que crece rapido Si se agregan muchas rutas el switch crece y se vuelve inmanejable, parecido a una enorme cadena de if-else en el frontend. Mantener y leer ese codigo se vuelve complejo.
3. Rutas dinamicas no soportadas Rutas como /users/123 o /products/456 requieren soporte para parametros en la ruta. Con switch estatico tendrias que escribir un caso por cada id posible, lo cual es inviable.
4. Firma de los handlers limitada Las funciones manejadoras en el ejemplo toman solo el ResponseWriter. En APIs reales necesitas acceder tambien al Request para leer query params, cabeceras y el cuerpo de la peticion.
Solucion rapida: soporte basico de metodos Antes de avanzar añadimos soporte para metodos HTTP leyendo r.Method y despachando segun metodo. Por ejemplo en ServeHTTP podemos hacer switch sobre method y llamar a s.handleGET o s.handlePOST pasando el Request y la ruta. Dentro de handleGET hacemos otro switch para rutas conocidas y en handlePOST lo mismo. Esto nos permite tener respuestas distintas para GET y POST en la misma ruta, pero la complejidad ya empieza a crecer rapidamente porque aparecen switch anidados y mas casos a mantener.
Ejemplo de comportamiento al probar curl curl -X GET https://localhost:3000/hello devuelve un saludo simple curl -X POST https://localhost:3000/hello devuelve una respuesta distinta curl -X PUT https://localhost:3000/hello devuelve metodo no permitido Este pequeño ejercicio muestra lo rapido que la solucion manual se complica cuando aumentan rutas y metodos.
Que sigue En el proximo capitulo construiremos un router adecuado, un componente separado encargado de casar rutas y metodos con handlers. Un router nos aportara separacion de responsabilidades, soporte sencillo para distintos metodos HTTP, facilidades para rutas dinamicas como /users/:id y una base mas solida para crecer de forma organizada. Es el equivalente a modularizar una aplicacion grande en lugar de mantener todo en un unico archivo.
Desafio Antes del Capitulo 3 intenta agregar algunas rutas mas para comprobar lo inmanejable que se vuelve el switch. Por ejemplo añade rutas para /api/users, /api/products y /api/orders con soporte tanto para GET como para POST. Veras como crece la complejidad y entenderas mejor el valor de un router.
Sobre Q2BSTUDIO y como podemos ayudar Q2BSTUDIO es una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida para empresas que necesitan soluciones escalables y seguras. Ademas somos especialistas en inteligencia artificial y ofrecemos servicios de ia para empresas, agentes IA y soluciones a medida que integran modelos de lenguaje con procesos de negocio. Si tu infraestructura necesita migracion o despliegue en la nube, ofrecemos servicios cloud aws y azure y diseñamos arquitecturas robustas para entornos productivos. Para proteger tus sistemas contamos con expertise en ciberseguridad y pentesting que detecta y mitiga riesgos antes de que afecten al negocio. Tambien apoyamos la toma de decisiones con servicios de inteligencia de negocio y Power BI que transforman datos en insights utilies.
Si buscas desarrollar una aplicacion web o movil completamente adaptada a tus requisitos revisa nuestras capacidades en aplicaciones a medida y software a medida y si tu proyecto requiere infraestructura en la nube podemos ayudarte con servicios cloud aws y azure. Tambien ofrecemos soluciones de inteligencia artificial para integrar agentes IA, automatizacion e inteligencia de negocio en tus procesos.
Palabras clave integradas aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws azure servicios inteligencia de negocio ia para empresas agentes IA power BI para mejorar posicionamiento. Si quieres que adaptemos este ejemplo a tu stack o necesitas que implementemos un router profesional, contacta con Q2BSTUDIO y te acompañamos desde el analisis hasta el despliegue y soporte continuo.
.jpg)