API

Analogía

La ventanilla de comida para llevar. No entras en la cocina ni tocas nada: pides por la ventanilla, en el formato que ellos aceptan, y te dan lo tuyo. La cocina puede cambiar por dentro y a ti te da igual, mientras la ventanilla siga igual.

Los dos usos que te vas a encontrar

1. La API que construyes tú para que tu frontend pida cosas a tu backend: "dame las citas de mañana", "guarda este cliente". → Fase 6
2. Las APIs de otros que integras en tu producto: cobrar con Stripe, enviar emails, mostrar un mapa, sincronizar un calendario. → Fase 9

Por qué esto es clave en el negocio

Casi nada se programa desde cero: se conecta. Por eso, cuando un cliente (negocio) ya usa un programa de facturación o un TPV, la primera pregunta profesional es: "¿tiene API?". Si la tiene, puedes integrarte con lo que ya usa. Si no, el proyecto se complica mucho.

Un paso más: cómo es una conversación con una API

Es una petición normal, pero en vez de una página para personas, devuelve datos para programas. Si tu web pide https://api.mirestaurante.com/platos, la respuesta puede ser:

[
  { "nombre": "Milanesa napolitana", "precio": 9500 },
  { "nombre": "Ensalada César", "precio": 6200 }
]

Ese formato de llaves y comillas se llama JSON: es la forma estándar de escribir datos para que los lea un programa. Tu frontend los recibe y decide cómo dibujarlos.

Cada dirección a la que se puede pedir algo es un endpoint (/platos, /reservas). Y cada API tiene su documentación: la lista de qué se puede pedir y cómo. Sin ella, una API es una ventanilla sin cartel.

Muchas APIs de otros exigen identificarse con una clave → secreto.

Un TPV es la caja registradora informatizada de un comercio (terminal punto de venta). Si un negocio ya tiene uno, que tenga API decide si tu sistema puede hablar con él.

Ver también

petición y respuesta · backend · HTTP / HTTPS · sistema a medida