certmundo.
es‑mx

6 min de lectura

¿Cómo consumir una API REST desde una aplicación real?

Consumir una API REST desde una aplicación real significa hacer peticiones HTTP desde tu código, procesar la respuesta y mostrar los datos al usuario.

Era lunes por la mañana. Daniela, desarrolladora en una startup de logística en Guadalajara, tenía una tarea clara: conectar el panel de administración de la empresa con la API de rastreo de envíos de FEMSA. No era su primera API, pero sí la primera vez que todo dependía de ella. El sistema de la bodega, los correos automáticos y el reporte diario del director general estaban esperando ese código. Tenía dos horas.

Lo que nadie te dice antes de conectar tu primera API real

La mayoría de los tutoriales te enseñan a hacer una sola petición y ver la respuesta en la terminal. Eso está muy bien para aprender. Pero en una aplicación real, el flujo es más complejo: necesitas autenticarte, manejar errores, transformar datos y mantener el código limpio para que otros lo entiendan.

Lo interesante es que más del 60% de los errores en integraciones de API no son técnicos. Son errores de flujo: el desarrollador no leyó bien la documentación, no manejó el caso cuando el servidor responde con 404, o guardó credenciales en el código fuente. Daniela lo sabía. Por eso empezó por lo correcto: leer la documentación completa antes de escribir una sola línea.

El ejemplo completo: un sistema de consulta de precios

Vamos a construir algo real. Imagina que trabajas para Liverpool y necesitas mostrar el precio de un producto en tu aplicación interna. La API que usarás tiene este endpoint:

GET https://api.liverpool.com.mx/v1/productos/{id}
Authorization: Bearer {token}

Usaremos dos lenguajes: Python y JavaScript. Así puedes elegir el que ya conoces.

Versión en Python con requests

Primero, instala la librería si no la tienes:

pip install requests

Ahora el código completo:

import requests
import os

BASE_URL = "https://api.liverpool.com.mx/v1"
TOKEN = os.environ.get("LIVERPOOL_API_TOKEN")

def obtener_producto(producto_id):
    url = f"{BASE_URL}/productos/{producto_id}"
    headers = {
        "Authorization": f"Bearer {TOKEN}",
        "Accept": "application/json"
    }

    try:
        respuesta = requests.get(url, headers=headers, timeout=5)

        if respuesta.status_code == 200:
            return respuesta.json()
        elif respuesta.status_code == 404:
            print("Producto no encontrado.")
            return None
        elif respuesta.status_code == 401:
            print("Token inválido o expirado.")
            return None
        else:
            print(f"Error inesperado: {respuesta.status_code}")
            return None

    except requests.exceptions.Timeout:
        print("La API tardó demasiado en responder.")
        return None
    except requests.exceptions.ConnectionError:
        print("No se pudo conectar con el servidor.")
        return None

producto = obtener_producto("SKU-00482")

if producto:
    nombre = producto["nombre"]
    precio = producto["precio"]
    stock = producto["stock"]
    print(f"Producto: {nombre}")
    print(f"Precio: ${precio:,.0f}")
    print(f"Disponibles: {stock} unidades")

Si la API responde correctamente, el programa imprime algo así:

Producto: Cafetera espresso Nespresso
Precio: $3,499
Disponibles: 12 unidades

Nota tres cosas importantes en este código. Primero, el token viene de una variable de entorno (os.environ.get), nunca escrito directamente en el código. Segundo, cada código de estado HTTP tiene su propio manejo. Tercero, hay un timeout=5 para no esperar eternamente si el servidor falla.

Versión en JavaScript con fetch

const BASE_URL = "https://api.liverpool.com.mx/v1";
const TOKEN = process.env.LIVERPOOL_API_TOKEN;

async function obtenerProducto(productoId) {
  const url = `${BASE_URL}/productos/${productoId}`;

  try {
    const respuesta = await fetch(url, {
      method: "GET",
      headers: {
        "Authorization": `Bearer ${TOKEN}`,
        "Accept": "application/json"
      }
    });

    if (respuesta.status === 200) {
      const datos = await respuesta.json();
      return datos;
    } else if (respuesta.status === 404) {
      console.log("Producto no encontrado.");
      return null;
    } else if (respuesta.status === 401) {
      console.log("Token inválido o expirado.");
      return null;
    } else {
      console.log(`Error inesperado: ${respuesta.status}`);
      return null;
    }

  } catch (error) {
    console.log("Error de red:", error.message);
    return null;
  }
}

obtenerProducto("SKU-00482").then(producto => {
  if (producto) {
    const precio = new Intl.NumberFormat("es-MX").format(producto.precio);
    console.log(`Producto: ${producto.nombre}`);
    console.log(`Precio: $${precio}`);
    console.log(`Disponibles: ${producto.stock} unidades`);
  }
});

Este código hace exactamente lo mismo que el de Python. La lógica es idéntica: petición, verificación de estado, manejo de errores, presentación de datos.

Cómo hacer una petición POST: crear un pedido

No solo leerás datos. También necesitarás enviar información. Así se hace un POST en Python para crear un pedido en un sistema de Bimbo:

def crear_pedido(datos_pedido):
    url = f"{BASE_URL}/pedidos"
    headers = {
        "Authorization": f"Bearer {TOKEN}",
        "Content-Type": "application/json"
    }

    respuesta = requests.post(url, json=datos_pedido, headers=headers, timeout=10)

    if respuesta.status_code == 201:
        nuevo_pedido = respuesta.json()
        print(f"Pedido creado con ID: {nuevo_pedido['id']}")
        return nuevo_pedido
    elif respuesta.status_code == 400:
        errores = respuesta.json().get("errores", [])
        print("Datos incorrectos:", errores)
        return None
    else:
        print(f"Error al crear pedido: {respuesta.status_code}")
        return None

pedido = {
    "cliente_id": "CLI-2847",
    "productos": [
        {"sku": "BIM-001", "cantidad": 50},
        {"sku": "BIM-045", "cantidad": 20}
    ],
    "direccion_entrega": "Av. Insurgentes Sur 1602, CDMX"
}

crear_pedido(pedido)

Observa que el header Content-Type: application/json le dice al servidor que estás enviando JSON. Si lo omites, muchas APIs rechazarán tu petición con un error 400.

Los tres errores más comunes al consumir APIs reales

Después de años integrando sistemas, los errores se repiten. El primero es no leer los mensajes de error del servidor. Cuando recibes un 400, el cuerpo de la respuesta casi siempre contiene un mensaje explicando exactamente qué salió mal. Léelo antes de buscar en Google.

El segundo error es ignorar los límites de tasa. Muchas APIs comerciales en México permiten entre 100 y 1,000 peticiones por minuto. Si haces un loop sin pausa y envías 5,000 peticiones en 10 segundos, recibirás un 429 Too Many Requests y tu IP podría bloquearse temporalmente. Agrega un time.sleep(0.1) entre peticiones masivas.

El tercer error es el más peligroso: hardcodear el token en el código fuente. Si subes ese código a GitHub, incluso en un repositorio privado, el token queda expuesto. Usa siempre variables de entorno. En Python es os.environ.get("MI_TOKEN"). En Node.js es process.env.MI_TOKEN. Es un hábito que debes formar desde hoy.

De vuelta con Daniela en Guadalajara

Dos horas después, Daniela había terminado. Su código hacía tres cosas: consultaba el estado del envío en la API de rastreo, transformaba los datos al formato que esperaba el panel interno y manejaba los casos donde el envío no existía o el token había expirado. Ciento cuarenta y dos líneas de Python, ordenadas y documentadas.

Lo que la hizo diferente no fue conocer todas las librerías. Fue entender el flujo completo: autenticación, petición, verificación de estado HTTP, transformación de datos y manejo de errores. Esos cinco pasos se repiten en cada integración, sin importar si es la API de FEMSA, del SAT o de Mercado Libre.

Lo que aprendiste en todo este curso

Empezaste preguntándote qué era una API REST. Hoy puedes diseñarla, documentarla y consumirla desde código real. Aprendiste que los verbos HTTP definen la acción, que los códigos de estado son el lenguaje de los errores y que la autenticación con tokens protege tus recursos. Viste por qué versionar desde /v1/ te salva de dolores de cabeza futuros, y por qué la paginación evita que tu servidor colapse.

El siguiente paso es practicar con APIs públicas reales. La API del SAT tiene documentación abierta. Mercado Libre ofrece una API gratuita para desarrolladores con la que puedes consultar productos, precios y vendedores. Conéctate a una de ellas esta semana. No importa si el primer intento falla. Lo que importa es que ya sabes exactamente dónde buscar el error.

Puntos clave

  • Siempre lee el token desde variables de entorno (`os.environ.get` o `process.env`). Nunca lo escribas directamente en el código fuente ni lo subas a GitHub.
  • Maneja cada código de estado HTTP por separado: `200` para éxito, `201` al crear, `401` para token inválido, `404` para recurso no encontrado y `400` para datos incorrectos.
  • Agrega siempre un `timeout` a tus peticiones para que tu aplicación no se congele si el servidor tarda demasiado o no responde.
  • Cuando recibes un error `400`, lee el cuerpo de la respuesta antes de buscar ayuda. El servidor casi siempre explica exactamente qué campo fue incorrecto.
  • El flujo de toda integración es siempre el mismo: autenticación → petición → verificar estado HTTP → transformar datos → manejar errores. Domina ese flujo y podrás consumir cualquier API.

Comparte esta lección: