API HTTP con Node y Express

Al finalizar, podrás levantar un servidor HTTP funcional en Node.js usando exclusivamente el módulo nativo `node:http` — sin Express ni frameworks — escribiendo `http.createServer((req, res) => …)`, configurando `server.listen(port)`, respondiendo con status 200 y `Content-Type: application/json`, leyendo el puerto desde `process.env.PORT`, y explicando por qué el Event Loop de Node + libuv permiten manejar miles de conexiones concurrentes con un solo hilo, además de identificar cuándo Bun o Deno serían alternativas válidas en 2026.

Al finalizar, podrás interpretar y construir peticiones HTTP con JSON desde la terminal usando curl — incluyendo Content-Type, Accept, Authorization y la inspección verbosa (-v) — para verificar contratos de tu API sin abrir un frontend.

Al finalizar, podrás construir una API REST mínima en Express con rutas GET/POST/PUT/DELETE, leer parámetros de URL, query string y body JSON, y decidir cuándo Express es la elección correcta frente a Hono o Fastify en 2026.

Al finalizar, podrás encadenar middlewares en una app Express aplicando el patrón Chain of Responsibility, registrar los cuatro middlewares estándar (helmet, cors, morgan, body-parser) en el orden correcto, escribir un middleware custom de timing con next(), y construir un error middleware con la firma de cuatro argumentos.

Al finalizar, podrás refactorizar un endpoint Express en tres capas — routes/users.ts (HTTP), services/userService.ts (reglas de negocio sin Express), repositories/userRepo.ts (acceso a datos) — aplicando la regla de dependencia de Clean Architecture (el dominio nunca importa Express ni Postgres) y decidir cuándo migrar de una estructura por tipo (routes/, services/, repositories/) a una por feature (users/, orders/, billing/) siguiendo Vertical Slice Architecture, con criterio observable: cuántos archivos tocas para añadir un campo a un endpoint.

Al finalizar, podrás configurar un pool de conexiones de PostgreSQL en Node.js usando `pg`, escribir queries parametrizadas con placeholders `$1, $2` para neutralizar el vector de SQL injection, decidir con criterio entre raw SQL, query builder y ORM (Prisma/Drizzle) según el contexto del proyecto, y aplicar las defensas de OWASP A03:2021 — Injection en el handler de Express.

Al finalizar, podrás validar cualquier input externo (req.body, req.query, req.params, headers, archivos) en un handler Express usando un schema zod reutilizable: defines el shape una vez con z.object, infieres el tipo TypeScript con z.infer, validas runtime con safeParse, devuelves 422 con issues estructurados si falla, y pasas el dato YA tipado al servicio — aplicando el patrón "Parse, don't Validate" (Alexis King, 2019) para que el resto de tu código no necesite re-comprobar nunca más esos campos.

Al finalizar, podrás centralizar el manejo de errores de una API Express con un middleware global de cuatro argumentos, una clase AppError tipada y un asyncWrapper que captura promesas rechazadas, distinguiendo errores operacionales (esperables: 4xx) de errores de programador (bugs: 5xx) según la clasificación de Joyent, y devolviendo respuestas seguras en formato RFC 7807 Problem Details sin filtrar stack traces ni datos sensibles en producción.

Al finalizar, podrás emitir y verificar JWT con jsonwebtoken (HS256), implementar un middleware requireAuth que pone req.user, distinguir cuándo usar JWT frente a sesiones HTTP, separar access tokens (cortos) de refresh tokens (rotativos), y elegir entre cookies HttpOnly Secure SameSite y el header Authorization Bearer según quién consume tu API — todo apoyado en RFC 7519 y RFC 6749 (OAuth 2.0).

Al finalizar, podrás endurecer una API Express y desplegarla a producción en Railway, Fly.io o Render en menos de 30 minutos, aplicando los controles mínimos del OWASP API Security Top 10 (2023) — helmet con CSP, CORS restringido al dominio del frontend, express-rate-limit en endpoints sensibles, bcrypt con cost factor adecuado, validación de entrada (L9), secretos vía variables de entorno (12-Factor App), HTTPS forzado y health checks — y revisando antes de cada push que ni .env ni claves de servicio viajan al repo, defendiendo cada decisión con la sección concreta del OWASP Top 10 que mitiga.