UD6 · Guía y taller práctico
Servidor web y API con Node
La unidad que cierra el módulo. Las rutas sueltas de la UD5 se convierten en una API diseñada: recursos, contrato, CRUD completo, capas separadas y un cliente que consume su propia API de punta a punta, con la configuración y las pruebas necesarias para publicarla.
Antes de empezar
- Necesitas
- El proyecto mi-api de la UD5, con Express, estáticos, registro y errores centralizados.
- El sitio de la UD1 a la UD4.
- Node.js 22 o superior, npm, un cliente HTTP y una cuenta en una plataforma de despliegue gratuita.
- Debes saber
- HTTP: métodos, rutas, cabeceras y códigos de estado (UD4 y UD5).
- Express: rutas, middleware, estáticos y manejo central de errores (UD5).
- Estado, render y fetch con sus estados de carga, error y vacío (UD4).
- Validación, JSON y módulos (UD3).
¿Qué vas a aprender?
En la UD5 conseguiste algo importante: un servidor propio que responde, aunque únicamente a un conjunto reducido de rutas incorporadas conforme fueron necesitándose.
Esta unidad convierte eso en un diseño.
- Rutas que funcionan
- Una API diseñada
- Una aplicación completa
- Publicada y defendida
Esta unidad cierra además el módulo completo. Al terminar habrás recorrido el recorrido íntegro: un documento con significado, un diseño que se adapta, una lógica que decide, una interfaz que reacciona, un servidor que responde y una aplicación que se publica.
La idea que gobierna la unidad
Una API es un contrato
Cuando alguien construye un cliente contra tu API, se apoya en que GET /api/productos/7 seguirá devolviendo lo mismo mañana, con la misma forma, y que un error seguirá teniendo la misma estructura. Cambiar eso sin avisar rompe programas ajenos.
Diseña por recursos, no por pantallas
La tentación es crear una ruta por cada cosa que necesita la interfaz: /api/datosDeLaPaginaDeInicio. Funciona hoy y ata la API a un diseño concreto: cambia la pantalla y hay que cambiar el servidor.
Una API se diseña sobre lo que existe en el problema —productos, categorías, pedidos— y sobre las operaciones que se hacen con ello. Las pantallas combinan esas piezas; no las definen.
El proyecto de la unidad
El mismo mi-api de la UD5, que crece hasta ser una aplicación:
mi-api/
│
├── package.json
├── .env.example
├── README.md
│
├── datos/
│ └── productos.json
│
├── src/
│ ├── servidor.js ← arranque y configuración
│ ├── app.js ← la aplicación Express
│ ├── rutas/
│ │ ├── productos.js
│ │ └── paginas.js
│ ├── servicio/
│ │ └── productos.js ← las reglas
│ ├── repositorio/
│ │ └── productos.js ← el acceso a los datos
│ ├── middleware/
│ │ ├── registro.js
│ │ └── errores.js
│ └── vistas/
│ └── catalogo.js ← HTML generado en el servidor
│
├── pruebas/
│ └── productos.test.js
│
└── publico/ ← el cliente de la UD4Una aplicación desplegada y accesible por URL: la web navegable, su API REST con el CRUD completo y su contrato de errores, las capas separadas, la configuración por entorno, las pruebas automáticas en verde y el README que explica cómo funciona.
Condición 1 · el andamiaje se retira
En la UD1 recibías cada paso explicado. Aquí recibes una especificación y decides tú la implementación. Habrá menos código en estos apuntes y más criterios, porque lo que se evalúa ya no es si sabes escribir una ruta, sino si sabes decidir cuál hace falta.
Condición 2 · nada llega al cliente sin validar, nada sale sin decidir
Todo lo que entra se valida en el servidor, y todo lo que sale constituye una decisión explícita: qué campos se devuelven, qué se oculta y qué se registra. Un objeto entero volcado en una respuesta acaba enseñando cosas que no debía.
Plan de trabajo semanal
| Semana | Bloque temático | Práctica central | Horas |
|---|---|---|---|
| Semana 1 | Diseñar la API | Recursos, contrato y estructura por capas | 3 h |
| Semana 2 | El CRUD completo | Lectura, creación, modificación y borrado | 3 h |
| Semana 3 | Capas y consistencia | Servicio, repositorio y contrato de errores | 3 h |
| Semana 4 | La web y su API | HTML del servidor y cliente conectado | 3 h |
| Semana 5 | Listo para publicar | Configuración, seguridad y pruebas | 3 h |
| Semana 6 | Cierre del módulo | Proyecto final, despliegue y defensa | 3 h |
| Total | Una aplicación web completa y publicada | 18 h |
- Recupera · 5 min
- Decide y diseña · 10–20 min
- Implementa · 30–40 min
- Cierra · 5 min
No todo pesa lo mismo
Sesiones de la unidad
Cada sesión es una clase, con su propia página.
18 sesiones
Semana 1 · Diseñar la API
Semana 2 · El CRUD completo
Semana 3 · Capas y consistencia
Semana 4 · La web y su API
Semana 5 · Listo para publicar
Semana 6 · Cierre del módulo