Cómo crear una API REST en Node.js

Todos los proyectos de Node.js acaban necesitando una API tarde o temprano. Las aplicaciones front-end necesitan datos. Las apps móviles necesitan algo con lo que comunicarse. Otros servicios necesitan puntos de acceso a los que conectarse.

Crear una API no es complicado, al menos en teoría. Pero en la práctica, es fácil meter la pata con los detalles. Códigos de estado incorrectos, respuestas incoherentes, puntos de conexión que no siguen las convenciones… La API funciona técnicamente, pero da la sensación de estar mal hecha en cuanto alguien intenta usarla.

En este blog te explico qué es una API REST, algunos principios de diseño que conviene conocer de antemano y, a continuación, te guío paso a paso por el proceso de creación de una pequeña API de inventario de productos de principio a fin. Además, al final te muestro cómo implementarla en el alojamiento Node.js gestionado de Cloudways.

¿Qué es una API REST y por qué usar Node.js

? REST es, básicamente, un conjunto de reglas para crear APIs HTTP. No hay nada más misterioso que eso.

Cada recurso (productos, usuarios, lo que sea) tiene su propia URL. Para interactuar con ellos, usas los métodos HTTP:

• Lecturas GET
• POST crea
• PUT y PATCH actualizan
• DELETE elimina

Cada respuesta viene acompañada de un código de estado. Los códigos que empiezan por 200 significan que todo ha salido bien. Los que empiezan por 400 significan que el cliente ha enviado una solicitud incorrecta. Los que empiezan por 500 significan que el servidor ha tenido un fallo. Los detalles importan aquí, pero esa es la idea general.

Node.js funciona muy bien para este tipo de cosas. El hecho de que se utilice JavaScript en ambos lados significa que se usa un solo lenguaje en toda la pila, lo cual es muy práctico. Además, se maneja muy bien un montón de peticiones simultáneas sin ralentizarse (eso es lo que se conoce como E/S sin bloqueo, por si has oído hablar de ello).

Express es lo que elige la mayoría de la gente. Es pequeño, discreto y hace bien una cosa. Combínalo con un par de paquetes de middleware y ya tienes todo lo que necesitas.

Principios de diseño de la API REST que conviene conocer

Algunas cosas que conviene tener claras antes de empezar a programar. Es más fácil hacerlo bien desde el principio que tener que cambiarlo después.

Los «endpoints» son sustantivos. No verbos.

/products está bien. /getProducts no. El método HTTP ya te indica la acción, así que la URL solo apunta a lo que hay que hacer.

Usa plurales para las colecciones. /products para la lista, /products/:id para un producto concreto. Es bueno que sea predecible.

Para los datos relacionados, anida las rutas. /products/:id/reviews se lee como «las reseñas de este producto». Muy claro.

Elige una convención de nomenclatura y no te desvíes de ella. Ya sea «kebab-case» o «camelCase», da igual cuál elijas. Eso sí, no las mezcles.

Los errores también deben tener un formato coherente. Si la mitad de tus puntos finales devuelven { error: «…» } y la otra mitad devuelven { message: «…», code: 400 }, quien utilice tu API tendrá que escribir código diferente para cada punto final. No mola nada.

Miniproyecto: Creación de la API de inventario de productos

Para este miniproyecto, crearé una API de inventario de productos. Permitirá agregar productos, listarlos (filtrando por categoría), obtenerlos por ID, actualizarlos y eliminarlos. Un CRUD básico, pero con la estructura adecuada.

Al final, esto se ejecuta localmente, se prueba con Postman y se implementa en un servidor en producción.

Requisitos

previos
. Antes de empezar:

• Node.js instalado
• Un editor de código (VS Code vale)
• Postman, Thunder Client o curl para hacer pruebas
• Conocimientos básicos de JavaScript y HTTP

Lo que voy a usar

• Node.js
• VS Code
• Express, better-sqlite3, dotenv, cors, helmet
• Postman para probar la API

Paso 1: Configurar el proyecto de Node.js

Tengo que asegurarme de que Node.js esté instalado y funcionando en mi ordenador antes de empezar a escribir código.

Como estoy trabajando con un portátil de la oficina que tiene restricciones informáticas muy estrictas, no puedo usar el instalador ejecutable estándar. En su lugar, voy a descargar el binario independiente para Windows directamente desde nodejs.org. He descomprimido el contenido del archivo y lo he guardado directamente en mi carpeta de Descargas.

Abro la carpeta del proyecto en la línea de comandos

A continuación, voy a mi escritorio y voy a crear una nueva carpeta para los archivos de mi proyecto llamada node-product-inventory-api.

Ahora voy a abrir la consola del Símbolo del sistema para poder ir directamente a esa ruta:

cd C:\Users\abdulrehman\Desktop\node-product-inventory-api

Dirigiendo el Símbolo del sistema al binario de Node

Como mi ordenador no utilizó un instalador oficial del sistema, el Símbolo del sistema aún no tiene una referencia global para el entorno de ejecución de Node. Tengo que vincular explícitamente la ruta usando la herramienta de la consola:

set PATH=%PATH%;C:\Users\abdulrehman\Downloads\node-v24.18.0-win-x64\node-v24.18.0-win-x64

Para comprobar rápidamente si mi terminal puede encontrar y usar los archivos de Node en mi ordenador, voy a ejecutar estos dos comandos de prueba:

node -v
npm -v

Como ambos comandos muestran la información de la versión, puedo pasar al siguiente paso, que es crear el proyecto de Node propiamente dicho.

Crear el proyecto de Node.js

Lo primero que tengo que hacer es inicializar el proyecto. Puedo hacerlo ejecutando el siguiente comando para generar un archivo package.json:

npm init -y

Ahora que ya tengo el archivo package.json, voy a descargar todas las bibliotecas externas específicas que necesito para desarrollar el backend de mi proyecto, como:

• Express para la capa de enrutamiento del servidor
• Better-sqlite3 para gestionar las operaciones del motor local
• Dotenv para gestionar las configuraciones
• CORS para ampliar los límites de acceso
• Helmet para añadir automáticamente los encabezados de seguridad que falten

Este es el comando que voy a ejecutar:

npm install express better-sqlite3 dotenv cors helmet

Paso 2: Configuración de la base de datos

Ahora que ya he creado mi proyecto de Node, voy a abrirlo en VS Code. Para ello, voy a abrir VS Code >, voy a ir a «Archivo» >, selecciono «Abrir carpeta» y elijo la carpeta «node-product-inventory-api» de mi escritorio.

Ahora que el proyecto está abierto en VS Code, ya puedo empezar a desarrollar el miniproyecto.

Primero, voy a crear una carpeta llamada «db» en la raíz del proyecto y, dentro de ella, un archivo llamado «database.js». Hago esto porque necesito un lugar donde guardar los productos con los que voy a interactuar mediante la API REST.

En el nuevo archivo que he creado, voy a pegar este fragmento de código:

const path = require('path');
const Database = require('better-sqlite3');
const db = new Database(path.join(__dirname, 'products.db'));
db.exec(`
CREATE TABLE IF NOT EXISTS products (
id INTEGER PRIMARY KEY AUTOINCREMENT,
sku TEXT UNIQUE NOT NULL,
name TEXT NOT NULL,
description TEXT,
price REAL NOT NULL,
quantity INTEGER NOT NULL DEFAULT 0,
category TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
`);
module.exports = db;

En el fragmento de código anterior, la restricción UNIQUE del campo «sku» garantiza que cada producto tenga un SKU único. Los campos «price» y «quantity» se han definido como NOT NULL porque son obligatorios para cada producto.

Paso 3: Creación de la base del servidor

Ahora voy a crear un archivo «server.js» en la raíz del proyecto y añadiré el siguiente código:

require('dotenv').config();
const express = require('express');
const cors = require('cors');
const helmet = require('helmet');
const db = require('./db/database');
const app = express();
const PORT = process.env.PORT || 3000;
app.use(helmet());
app.use(cors());
app.use(express.json());
app.get('/', (req, res) => {
res.json({
status: 'ok',
message: 'Product Inventory API is running',
});
});
app.listen(PORT, () => {
console.log(`Server running on port ${PORT}`);
});

En el fragmento de código de arriba, he usado Helmet para configurar los encabezados de seguridad habituales. Además, he usado CORS para permitir solicitudes de otros orígenes.

También he usado express.json() porque voy a enviar datos JSON desde Postman cuando pruebe los puntos finales de mi API.

La ruta raíz servirá como una sencilla comprobación de estado. Una vez realizada la implementación, puedo acceder a la URL base para comprobar que la API funciona correctamente.

Paso 4: Crear los puntos finales CRUD

Ahora voy a crear los puntos finales para las operaciones CRUD. Y cada punto final que cree, lo añadiré al archivo server.js, encima de la línea app.listen(…).

GET /products (con filtro de categoría opcional)

app.get('/products', (req, res) => {
const { category } = req.query;
try {
let products;
if (category) {
products = db
.prepare(
'SELECT * FROM products WHERE category = ? ORDER BY created_at DESC'
)
.all(category);
} else {
products = db
.prepare('SELECT * FROM products ORDER BY created_at DESC')
.all();
}
res.json({ count: products.length, products });
} catch (err) {
console.error(err);
res.status(500).json({ error: 'Failed to fetch products' });
}
});

En este fragmento de código, he usado el parámetro de consulta «category». Es totalmente opcional, pero si lo incluyo (por ejemplo, /products?category=electronics), la API debería devolver solo los productos que coincidan. Si no, devolverá todos los productos.

GET /products/:id

app.get('/products/:id', (req, res) => {
try {
const product = db
.prepare('SELECT * FROM products WHERE id = ?')
.get(req.params.id);
if (!product) {
return res.status(404).json({ error: 'Product not found' });
}
res.json({ product });
} catch (err) {
console.error(err);
res.status(500).json({ error: 'Failed to fetch product' });
}
});

Uso este punto final para buscar un producto por su ID. Si el ID no existe, la API te devolverá un error 404 en lugar de una respuesta vacía.

POST /products

app.post('/products', (req, res) => {
const { sku, name, description, price, quantity, category } = req.body;
if (!sku || !name || price === undefined) {
return res
.status(400)
.json({ error: 'sku, name, and price are required' });
}
try {
const result = db
.prepare(`
INSERT INTO products
(sku, name, description, price, quantity, category)
VALUES
(?, ?, ?, ?, ?, ?)
`)
.run(
sku,
name,
description || null,
price,
quantity || 0,
category || null
);
const newProduct = db
.prepare('SELECT * FROM products WHERE id = ?')
.get(result.lastInsertRowid);
res.status(201).json({ product: newProduct });
} catch (err) {
if (err.code === 'SQLITE_CONSTRAINT_UNIQUE') {
return res
.status(400)
.json({ error: 'A product with that SKU already exists' });
}
console.error(err);
res.status(500).json({ error: 'Failed to create product' });
}
});

Este punto final creará un nuevo producto. He incluido algunas validaciones básicas para asegurarme de que se rellenen los campos «sku», «nombre» y «precio» antes de que la solicitud llegue a la base de datos.

El código también comprobará si hay SKU duplicados y devolverá una respuesta 400 en caso de encontrar uno.

Si no hay errores, la API devolverá un código 201, que es la respuesta estándar cuando se crea un recurso correctamente.

PUT /products/:id

app.put('/products/:id', (req, res) => {
const { sku, name, description, price, quantity, category } = req.body;
const existing = db
.prepare('SELECT * FROM products WHERE id = ?')
.get(req.params.id);
if (!existing) {
return res.status(404).json({ error: 'Product not found' });
}
try {
db.prepare(`
UPDATE products
SET
sku = ?,
name = ?,
description = ?,
price = ?,
quantity = ?,
category = ?
WHERE id = ?
`).run(
sku ?? existing.sku,
name ?? existing.name,
description ?? existing.description,
price ?? existing.price,
quantity ?? existing.quantity,
category ?? existing.category,
req.params.id
);
const updated = db
.prepare('SELECT * FROM products WHERE id = ?')
.get(req.params.id);
res.json({ product: updated });
} catch (err) {
console.error(err);
res.status(500).json({ error: 'Failed to update product' });
}
});

Este endpoint actualizará un producto ya existente. He usado el símbolo «??» para indicar que cualquier campo que no se incluya en la solicitud mantenga su valor actual. Así, puedo actualizar solo los campos que quiero cambiar, en lugar de enviar el objeto completo del producto.

BORRAR /productos/:id

app.delete('/products/:id', (req, res) => {
try {
const result = db
.prepare('DELETE FROM products WHERE id = ?')
.run(req.params.id);
if (result.changes === 0) {
return res.status(404).json({ error: 'Product not found' });
}
res.json({ message: 'Product deleted' });
} catch (err) {
console.error(err);
res.status(500).json({ error: 'Failed to delete product' });
}
});

Este punto final eliminará un producto por su ID. Si el ID no existe, devuelve una respuesta 404. En caso contrario, devolverá un mensaje de éxito confirmando que el producto se ha eliminado.

Paso 5: Agregar manejo global de errores

Ya he añadido el manejo de errores en cada endpoint, pero por si acaso, también añadiré una reserva global para cualquier cosa que se me haya pasado por alto. Así que añadiré el siguiente código al final del archivo server.js, justo antes de app.listen(…):

app.use((req, res) => {
res.status(404).json({ error: 'Route not found' });
});
app.use((err, req, res, next) => {
console.error(err);
res.status(500).json({ error: 'Something went wrong on our end' });
});

El primer middleware devolverá una respuesta 404 Not Found para cualquier ruta que no esté definida. El segundo detectará los errores inesperados que no se hayan gestionado en otro sitio.

Paso 6: Probar la API con Postman

Ya es hora de probarlo de verdad. Voy a añadir un script de inicio a mi «package.json» para no tener que estar escribiendo siempre el comando completo de Node:

"scripts": {
"start": "node server.js",
"test": "echo \"Error: no test specified\" && exit 1"
}

Después, volveré a la línea de comandos y ejecutaré:

npm start

Ahora mi servidor está funcionando en el puerto 3000. Para probar cada punto final que he creado antes, voy a usar Postman.

Crea un producto: envía una solicitud POST a http://localhost:3000/products con un cuerpo en formato JSON:

{
"sku": "LAPTOP-001",
"name": "Silver Laptop",
"description": "A 14-inch aluminum laptop",
"price": 1299.99,
"quantity": 10,
"category": "electronics"
}

Si la solicitud se realiza correctamente, veré una respuesta 201, el producto recién creado, incluyendo su ID generado automáticamente.

A continuación, enviaré una solicitud GET a http://localhost:3000/products para recuperar todos los productos.

Si añado un parámetro de consulta como ?category=electronics, la API solo te mostrará los productos de esa categoría.

Entonces puedo cambiar el parámetro a ?category=Portable para recuperar un producto de otra categoría.

A continuación, voy a probar a recuperar un solo producto con una solicitud GET a http://localhost:3000/products/1.

Si pruebo con un ID que no existe, como /products/999, la API te devolverá un error 404.

Para probar el punto final de actualización, voy a enviar una solicitud PUT a http://localhost:3000/products/1 con solo el campo «price» que quiero cambiar. Por ejemplo, { «price»: 1199.99 }.

Ahora, solo se actualiza el precio, y el resto de los campos se mantienen igual.

Por último, voy a enviar la solicitud DELETE a http://localhost:3000/products/1 para eliminar el producto con el ID «1».

Si intento recuperar el producto eliminado, me saldrá una respuesta 404, lo que confirma que se ha eliminado antes.

¡Uf! Todos los puntos finales CRUD funcionan como se esperaba.

Paso 7: Prepararlo para el despliegue

Antes de subir mi proyecto al alojamiento gestionado de Node.js de Cloudways, haré unos pequeños cambios para dejarlo listo para el despliegue.

Primero, voy a crear un archivo .env en la raíz del proyecto y voy a pegar este código en él:

NODE_ENV=development

De momento no hay nada confidencial guardado en este archivo, pero me gusta prepararlo con antelación. Cuando implemente la aplicación, cambiaré «development» por «production».

También crearé un archivo .gitignore y pegaré este código en él:

node_modules
.env
db/products.db

He excluido el archivo de la base de datos porque el servidor de producción debería empezar con una base de datos nueva, no con los datos de ejemplo que he estado usando en el entorno de producción local.

Paso 8: Subir el proyecto a GitHub

Ahora que ya lo tengo todo listo, voy a subir el proyecto a GitHub. Primero, voy a crear un nuevo repositorio llamado node-product-inventory-api.

Después, voy a abrir el Símbolo del sistema y ejecutaré los siguientes comandos uno por uno:

git init
git add .
git commit -m "First commit"
git branch -M main
git remote add origin https://github.com/abdulrehman293/node-product-inventory-api
git push -u origin main

Una vez que se haya completado el push, actualizaré el repositorio en GitHub. Y ahora puedo ver todos los archivos del proyecto, sin contar el .env, node_modules y el archivo de la base de datos local.

Paso 9: Implementación en Cloudways

Ahora que ya he subido el proyecto a GitHub, estoy listo para implementarlo. Para ello, voy a usar el alojamiento gestionado de Node.js de Cloudways.

En el panel de control de Cloudways, voy a hacer clic en «Node.js» en el menú de la izquierda y, a continuación, voy a pulsar «Lanzar ahora».

El plan Starter está bien para algo de este tamaño.

En la siguiente pantalla, haré clic en «Conectar vía Git» y me conectaré a GitHub.

Una vez conectado, elegiré mi repositorio «node-product-inventory-api» y haré clic en «Continuar».

Ahora voy a elegir «Express» como configuración predeterminada del marco de trabajo. La versión de Node la pondré en Node 24 (LTS). Y dejaré el directorio raíz tal y como está por defecto.

A continuación, haré clic en «Cambiar» en «Configuración de compilación y salida», configuraré el gestor de paquetes como npm y dejaré el «Archivo de entrada» como server.js.

Ahora, haré clic en «Añadir» junto a «Variables de entorno» y añadiré NODE_ENV como clave y production como valor.

Después de guardar los cambios, haré clic en «Implementar ahora». Cloudways empezará a descargar el código más reciente de GitHub e instalará las dependencias del proyecto.

El momento de la verdad

Una vez que la implementación se haya realizado con éxito, copiaré la URL temporal de Cloudways de la página de resumen de la aplicación y volveré a Postman.

Antes usaba la URL de localhost, pero ahora la voy a cambiar por la URL temporal de Cloudways para probar cada punto final.

GET

. Primero voy a enviar la solicitud GET a la URL base. Si todo está bien configurado, me aparecerá el mensaje «Product Inventory API is running», lo que confirma que la API está activa.

Después probaré el resto de los demás puntos finales. Crear un producto. Mostrar la lista. Recuperar por ID. Actualizar. Eliminar. Lo mismo que hice en el entorno local, pero esta vez con la URL de producción.

PUBLICAR

PUT

BORRAR

Ahora bien, si intento recuperar el producto eliminado, me devolverá un código de estado 404.

Conclusión

Con esto terminamos nuestra guía sobre cómo crear una API REST con Node.js. En esta guía, he explicado qué es REST, he repasado algunos principios de diseño que conviene conocer y, a continuación, he creado una API de inventario de productos con puntos finales CRUD completos, validación y gestión de errores.

También he mostrado cómo probarlo todo localmente con Postman y, después, he desplegado el proyecto en un servidor de Cloudways en producción.

He subido el proyecto terminado a mi GitHub, así que podéis clonarlo y reutilizar el código. Y si queréis intentar implementar algo parecido por vuestra cuenta, nuestro servicio de alojamiento gestionado de Node.js se encarga de este proceso sin problemas: conectad vuestro repositorio, elegid una configuración predefinida del framework y publicad vuestra aplicación.

[email protected]

Abdul es un experto en tecnología, aficionado al café y al marketing creativo al que le encanta estar al día de las últimas actualizaciones de software y aparatos tecnológicos. También es un hábil escritor técnico capaz de explicar conceptos complejos de forma sencilla para un público amplio. Abdul disfruta compartiendo sus conocimientos sobre el sector de la Nube a través de manuales de usuario, documentación y entradas de blog.

Get Connected on: Twitter Community Forum