¿Qué es una API (Interfaz de Programación de Aplicaciones)?

Una API es un conjunto de reglas que permite a una aplicación solicitar datos y funcionalidad de otra sin conocer su código interno. La famosa analogía del restaurante — pides del menú, la cocina permanece invisible — se gana su única frase y nada más, porque la realidad enseña más que la metáfora: una API es un contrato, y los contratos son precisos.

Puntos clave

Anatomía de una solicitud y respuesta de API HTTP

Ningún explicador de los rankings muestra una, así que aquí va una llamada de API entera — request y respuesta, sin esconder nada:

POST /classes/Todo HTTP/1.1              ← método + endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← identifica a la app que llama
Authorization: Bearer eyJhbGci…          ← autentica al usuario
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← estado: funcionó, recurso creado
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }

La misma llamada a través de un SDK — que no es más que este HTTP, envuelto en el idioma de tu lenguaje:

// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);

// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');

// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}

// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}

Cómo funciona una llamada de API

Tres propiedades de este ciclo explican por qué las APIs sostienen el stack moderno. Abstracción: quien llama necesita el contrato, nunca la implementación — el proveedor puede reescribir todo detrás de la interfaz sin romper un solo cliente. Frontera: la validación y los permisos viven en la interfaz, y por eso los clientes hablan con APIs y nunca con la base de datos directamente — una API no es una base de datos; es el guardián frente a una. Composición: como cada capacidad es invocable, las aplicaciones se ensamblan a partir de servicios — auth aquí, pagos allá, mapas de un tercero — y, cada vez más, los agentes de IA usan el mismo sustrato: el tool calling es llamar APIs con un modelo decidiendo las requests.

El contrato: lo que una API promete en realidad

Las páginas que llaman a una API “un contrato” rara vez muestran uno. Hoy el contrato es un documento legible por máquinas — la OpenAPI Specification es el estándar para APIs HTTP — que lista cada endpoint, parámetro, esquema y código de estado. A partir de ese único archivo, las herramientas generan documentación de referencia, bibliotecas cliente, stubs de servidor, servidores mock y pruebas de contrato.

El encuadre de contrato tiene dientes por el versionado. Agregar un campo a la respuesta no rompe a nadie; renombrar o eliminar uno rompe a cada consumidor en silencio — por eso las APIs maduras distinguen los cambios aditivos de los que rompen, versionan su superficie (/v1/, o vía headers) y publican ventanas de deprecación. Una API sin política de cambios es un contrato sin cláusulas: técnicamente una promesa, en la práctica una sorpresa.

Los tipos de APIs

Con forma de consulta, porque “tipos de APIs” es una búsqueda en sí misma: dos taxonomías, no una.

Por audiencia:

Por estilo: REST (recursos en URLs, métodos HTTP), GraphQL (consultas moldeadas por el cliente en un solo endpoint), gRPC (binario, contract-first, de servicio a servicio), SOAP (sobres XML, estándares enterprise/legacy) y APIs de WebSocket (bidireccionales, persistentes) — comparados en la siguiente tabla.

Y un párrafo que los explicadores de la web se saltan: no toda API es una API web. La biblioteca estándar de un lenguaje, las llamadas al sistema POSIX y las interfaces fetch y de geolocalización integradas en el navegador son todas APIs — contratos entre programas — que nunca cruzan una red. La variante web solo puso el contrato detrás de una URL.

REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

Casos de uso comunes

• Backends móviles y web — los datos de cada pantalla llegan a través de una API; el frontend nunca toca la base de datos.
• Integración con terceros — pagos, identidad, mensajería, mapas: capacidades alquiladas mediante contratos en lugar de reconstruidas.
• Comunicación entre microservicios — APIs internas como las costuras que dejan a los servicios desplegarse y escalar de forma independiente.
• Automatización y scripting — todo lo que tiene API se puede orquestar: pipelines de CI, infraestructura, flujos de contenido.
• Agentes de IA y tool calling — los modelos actúan invocando APIs; un contrato bien documentado hoy lo consumen las máquinas dos veces: los SDKs y los agentes.

¿Qué estilo de API deberías elegir? Matriz de decisión

Limitaciones y trade-offs

• Un contrato también ata al proveedor. Cada campo publicado se vuelve algo de lo que alguien depende; la evolución ocurre con disciplina de versionado, no con ediciones silenciosas.
• Las APIs de red heredan la red. La latencia, las fallas parciales y los reintentos son parte de la semántica de cada llamada remota — las llamadas a funciones locales nunca necesitaron políticas de timeout.
• La abstracción esconde el costo. Una llamada de aspecto inocente puede desplegarse en trabajo caro; los consumidores ven el menú, no la cuenta de la cocina — para eso existen los rate limits y las cuotas.
• La superficie de seguridad crece con la superficie. Cada endpoint es una puerta; las keys identifican pero no autorizan, así que la auth real (tokens estilo OAuth 2.0, permisos por usuario) y la validación de entrada son lo mínimo indispensable.
• Las formas fijas no les quedan a todos los consumidores. Los trade-offs de overfetching/underfetching del diseño de endpoints son un tema propio — mira la entrada hermana.

APIs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La jugada definitoria es que la API se genera, no se construye: define un modelo de datos y la plataforma lo expone de inmediato como endpoints REST y un esquema GraphQL — la llamada diseccionada de arriba es formato de cable real de Back4app — con keys, tokens de usuario y permisos a nivel de clase haciendo cumplir el contrato en la frontera. Los SDKs consumen esa API de forma idiomática desde cada plataforma principal, y las operaciones personalizadas se vuelven funciones de Cloud Code: endpoints nuevos en un archivo, la misma disciplina de contrato, sin servidor que operar.