Node.js es un entorno que ejecuta JavaScript fuera del navegador, en el servidor, lo que permite usar un solo lenguaje en toda la aplicación. Express es un marco minimalista para Node que reduce a pocas líneas lo que sería mucho código a mano para atender peticiones web. Juntos son una de las formas más directas de implementar una API REST. El patrón es simple: se define una ruta por cada combinación de método y recurso (app.get('/pedidos/:id', ...)), y en cada una se recibe la petición (req, con sus parámetros y su cuerpo) y se envía la respuesta (res, con el código de estado y los datos). El middleware son funciones que se ejecutan antes de las rutas —para leer el JSON del cuerpo, autenticar, registrar—. Y una regla que no se negocia: los secretos (claves, contraseñas de la base de datos) van en variables de entorno, nunca en el código. Esta guía implementa lo que la de conceptos de REST explica.
Ver índice de contenidos
Qué son Node y Express
Durante años, JavaScript solo corría en el navegador. Node.js cambió eso: es un entorno que ejecuta JavaScript en el servidor, con acceso a archivos, red y bases de datos. Su gran atractivo es que permite escribir el backend y el frontend en el mismo lenguaje, reutilizando conocimiento y a veces código.
Express es un marco web para Node: una capa que resuelve las tareas repetitivas de atender peticiones —enrutar según la dirección, leer el cuerpo, enviar respuestas— para que no haya que programarlas a mano cada vez. Es minimalista a propósito: no impone una estructura, da las piezas y vos armás.
Antes de esta conviene leer cómo crear y consumir una API REST, que cubre los conceptos independientes del lenguaje: métodos, códigos de estado, recursos y rutas. Esta guía los implementa en Node y Express. Si ya entendés REST, vas a ver que Express es casi una traducción directa de esas ideas a código.
Tu primera API
Una API mínima con Express cabe en pocas líneas. Node se instala desde su sitio oficial, y Express con el gestor de paquetes:
// npm install express · luego, en un archivo del proyecto:
import express from 'express';
const app = express();
app.use(express.json()); // middleware: entender cuerpos JSON
// Una ruta: método GET sobre el recurso raíz.
app.get('/', (req, res) => {
res.json({ mensaje: 'Mi primera API funciona' });
});
// Encender el servidor en un puerto.
app.listen(3000, () => console.log('Escuchando en el puerto 3000'));Con eso, al pedir la raíz del servidor, la API responde con un JSON. Cada ruta recibe dos objetos: req (la petición: sus parámetros, su cuerpo, sus cabeceras) y res (la respuesta: con qué contestar). Ese par petición-respuesta es el corazón de todo.
Rutas para cada recurso
Una API REST se implementa definiendo una ruta por cada combinación de método + recurso. La correspondencia con los conceptos de REST es directa:
// Listar todos los pedidos.
app.get('/pedidos', (req, res) => {
res.json(pedidos);
});
// Leer uno por su identificador (:id es un parámetro de la ruta).
app.get('/pedidos/:id', (req, res) => {
const pedido = buscarPorId(req.params.id);
if (!pedido) return res.status(404).json({ error: 'No existe' });
res.json(pedido);
});
// Crear uno nuevo: lee el cuerpo, responde 201 (creado).
app.post('/pedidos', (req, res) => {
const nuevo = crear(req.body);
res.status(201).json(nuevo);
});Lo importante: usar el código de estado correcto en cada caso —404 si no existe, 201 si se creó— es parte de implementar bien REST, no un detalle. Y como las operaciones reales (consultar una base de datos) son asíncronas, las rutas suelen usar async/await con su try/catch para no dejar errores sin manejar.
El middleware
El middleware es la idea que más define a Express: funciones que se ejecutan en orden, antes de llegar a la ruta, y que pueden inspeccionar o modificar la petición, o cortarla. Es una cadena por la que pasa cada petición.
- Leer el cuerpo.
express.json()interpreta el JSON que llega y lo deja disponible enreq.body. Sin él, el cuerpo no se entiende. - Autenticar. Un middleware que verifica el token de la petición y la corta con
401si no es válido, antes de que llegue a la ruta protegida. - Registrar. Anotar cada petición que entra, para diagnóstico.
- Manejar errores. Un middleware final que atrapa los errores de todas las rutas y responde de forma consistente.
El middleware evita repetir lo mismo en cada ruta: en vez de leer el cuerpo o verificar el token dentro de cada una, se hace una vez en la cadena. Es la aplicación directa del principio de no repetir código que ordena el código limpio.
Antes de llevarla a producción
Una API que funciona en tu máquina necesita algunas cosas más para el mundo real, y una es innegociable:
Las claves de servicios, las contraseñas de la base de datos y cualquier credencial nunca van escritas en el código, que se versiona y se comparte. Van en variables de entorno, que el programa lee al arrancar y que no se suben al repositorio. Es la misma regla que en los pipelines y en la administración de servidores: los secretos no viven en el código.
Además, antes de exponerla: validar las entradas (nunca confiar en lo que llega del cliente, como se ve en SQLi, XSS y CSRF), manejar todos los errores para no filtrar detalles internos, servir siempre por HTTPS, y probarla con Postman y Newman. Dónde se despliega —un servidor propio con Nginx delante, o un servicio de nube— es el paso final.
Errores frecuentes
- Escribir secretos en el código. Van en variables de entorno, fuera del repositorio. Sin excepción.
- Olvidar el middleware que lee el cuerpo. Sin
express.json(),req.bodyllega vacío y confunde. - Devolver siempre 200. Usar el código de estado correcto es implementar bien REST, no un adorno.
- No manejar los errores asíncronos. Una consulta que falla sin
try/catchpuede tumbar el servidor. - Confiar en la entrada del cliente. Todo lo que llega se valida; es la puerta de las inyecciones.
- Repetir lógica en cada ruta. Lo común —autenticar, registrar— va en middleware.
- Saltar los conceptos de REST. Implementar sin entender método, ruta y estado lleva a APIs inconsistentes.
Preguntas frecuentes
¿Qué son Node.js y Express?
Node.js es un entorno que permite ejecutar JavaScript fuera del navegador, en el servidor, con acceso a archivos, red y bases de datos. Su gran atractivo es que permite usar el mismo lenguaje tanto en el frontend como en el backend, reutilizando conocimiento y a veces código. Express es un marco web minimalista construido sobre Node: una capa que resuelve las tareas repetitivas de atender peticiones web —enrutar según la dirección, leer el cuerpo de la petición, enviar respuestas— para que no haya que programarlas a mano cada vez. Es deliberadamente minimalista: no impone una estructura ni un montón de decisiones, sino que ofrece las piezas básicas y deja que uno arme la aplicación como prefiera. Juntos son una de las formas más directas y populares de implementar una API REST, especialmente para quien ya sabe JavaScript.
¿Cuál es la diferencia entre esta guía y la de conceptos de API REST?
La guía de conceptos de API REST explica las ideas independientes del lenguaje: qué es REST, los métodos de HTTP, los códigos de estado, cómo se diseñan los recursos y las rutas, y cómo se consume una API. Son los fundamentos que sirven en cualquier tecnología. Esta guía, en cambio, es la implementación concreta de esas ideas usando Node y Express: cómo se define efectivamente una ruta en código, cómo se reciben la petición y se envía la respuesta, qué es el middleware y cómo se manejan los errores. La recomendación es leer primero la de conceptos y después esta, porque una vez que se entienden las ideas de REST, la implementación con Express resulta casi una traducción directa de esas ideas a código, y todo lo que en un principio parecería complejo se vuelve evidente.
¿Qué es el middleware en Express?
Es el concepto que más define a Express: funciones que se ejecutan en orden, antes de que la petición llegue a la ruta que la atiende, formando una cadena por la que pasa cada petición. Cada middleware puede inspeccionar o modificar la petición, o cortarla respondiendo directamente. Se usa para tareas comunes que no conviene repetir en cada ruta: leer e interpretar el cuerpo de la petición en formato JSON para dejarlo disponible, verificar la autenticación y rechazar con un error las peticiones sin credenciales válidas antes de que lleguen a una ruta protegida, registrar cada petición para diagnóstico, o atrapar los errores de todas las rutas y responder de forma consistente. La ventaja es que centraliza esa lógica compartida en un solo lugar, en lugar de repetirla en cada ruta, aplicando el principio de no repetir código.
¿Dónde guardo las claves y contraseñas de mi API?
En variables de entorno, nunca escritas en el código. Esta es una regla que no se negocia, porque el código se versiona y se comparte, así que cualquier secreto escrito en él —una clave de un servicio, la contraseña de la base de datos, un token— queda expuesto a quien tenga acceso al repositorio, y una vez filtrado es muy difícil de revertir. Las variables de entorno son valores que el programa lee del sistema al arrancar y que se mantienen fuera del código y fuera del control de versiones. Así, el mismo código puede correr en tu máquina, en pruebas y en producción con credenciales distintas, sin que ninguna quede registrada. Es exactamente la misma regla que se aplica en los pipelines de integración continua y en la administración de servidores: los secretos viven en un mecanismo aparte pensado para protegerlos, no en el código.
¿Por qué necesito async/await al crear una API?
Porque casi todas las operaciones reales que hace una API son asíncronas: consultar una base de datos, llamar a otro servicio o leer un archivo son tareas que tardan y cuyo resultado llega después, no de inmediato. Si la ruta no espera correctamente ese resultado, intentaría responder con datos que todavía no están. La sintaxis de async y await permite escribir esas rutas de forma que esperen el resultado sin bloquear el servidor y con un código que se lee de arriba hacia abajo. Además, es imprescindible envolver esas operaciones en un manejo de errores, porque una consulta que falla sin ser atrapada puede llegar a tumbar el servidor entero. Por eso, entender bien la programación asíncrona en JavaScript es un requisito previo para construir una API sólida, y conviene tenerlo claro antes de encarar el backend.
¿Node y Express son la única opción para hacer una API?
No, son una opción muy popular pero de ninguna manera la única. Prácticamente todos los lenguajes tienen marcos maduros para construir APIs: en Python están opciones muy usadas para servicios web, y lo mismo ocurre en otros lenguajes ampliamente adoptados en el backend. La gran ventaja de Node con Express es que permite usar JavaScript tanto en el servidor como en el navegador, lo que resulta muy cómodo para quien ya sabe JavaScript del lado del cliente y quiere extender ese conocimiento al backend sin aprender otro lenguaje. Pero lo verdaderamente importante y transferible son los conceptos de REST, que son iguales en cualquier tecnología: una vez que se entienden los métodos, los códigos de estado y el diseño de recursos, implementarlos en Express, en un marco de Python o en cualquier otro es solo cuestión de aprender la sintaxis particular de cada uno.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Desarrollo web. Consultas sobre backend, Node, Express y APIs.
- Underc0de, foro. Sección Programación. Arquitectura de servicios y buenas prácticas.
Documentación oficial
- OpenJS Foundation. Node.js. El entorno que ejecuta JavaScript en el servidor.
- Express. Express, en español. El marco web minimalista usado en la guía.
- Mozilla. Express/Node en MDN. Tutorial de referencia del lado del servidor.
- IETF. RFC 9110, HTTP Semantics. La semántica de HTTP que la API respeta.