---
term: 'API (Interfaz de Programación de Aplicaciones)'
seoTitle: '¿Qué es una API? Interfaz de Programación de Aplicaciones'
headline: '¿Qué es una API (Interfaz de Programación de Aplicaciones)?'
slug: api
category: api-realtime
shortDefinition: '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.'
relatedTerms:
  - rest-api
  - graphql-vs-rest
  - backend-sdk
  - auto-generated-database-apis
  - api-gateway-architecture
contrastsWith:
  - backend-sdk
faq:
  - question: '¿Qué significa API?'
    answer: 'Application Programming Interface — en español, Interfaz de Programación de Aplicaciones. "Aplicación" es cualquier software con una función propia; "interfaz" es el contrato entre dos de ellas — el conjunto definido de solicitudes que una puede hacer y las respuestas que la otra promete devolver. La parte de programación es el punto: es una interfaz para software, donde una UI es una interfaz para humanos.'
  - question: '¿Qué es una API y para qué sirve?'
    answer: 'Un mensajero con un menú. Un programa expone una lista de cosas que puede hacer — traer estos datos, ejecutar aquella acción — y otros programas las invocan mediante requests definidas, sin ver jamás cómo ocurre el trabajo por dentro. Sirve para integrar sistemas sin acoplarlos: la ilustración clásica es una app del clima que no mide el cielo; llama a la API de un servicio meteorológico.'
  - question: '¿Cómo funciona una API?'
    answer: 'Por solicitud y respuesta. El cliente envía una request a un endpoint — una URL que nombra el recurso — con un método que declara la intención, headers que llevan metadatos y credenciales, y a veces un cuerpo con datos. El servidor la valida, hace el trabajo y devuelve un código de estado más un cuerpo de respuesta, normalmente JSON. Toda integración que hayas usado se reduce a este ciclo.'
  - question: '¿Cuál es un ejemplo de API?'
    answer: 'Iniciar sesión con un proveedor de identidad, el paso de pago de un checkout, un mapa incrustado en una app de delivery, un widget del clima — cada uno es una aplicación llamando a la API de otra. Los ejemplos para desarrolladores son aún más directos: una plataforma de backend que expone tu base de datos como endpoints HTTP que tu app móvil consulta.'
  - question: '¿Cuál es la diferencia entre una API y un SDK?'
    answer: 'La API es el contrato; un SDK es una caja de herramientas para consumirlo. Un SDK envuelve las llamadas a la API en funciones idiomáticas de tu lenguaje y suma manejo de sesión, reintentos y tipos. A una API la llamas por la red; un SDK lo importas en tu código — y por debajo, el SDK está haciendo llamadas a la API.'
  - question: '¿Qué tipos de APIs existen?'
    answer: 'Por audiencia: públicas (abiertas a cualquier desarrollador), de socios (compartidas con empresas bajo contrato), internas (privadas de una organización) y compuestas (que agrupan varias llamadas). Por estilo: REST, GraphQL, gRPC, SOAP y APIs de WebSocket. Y más allá de la web: APIs de bibliotecas y de sistemas operativos — las interfaces existían mucho antes de que HTTP las transportara.'
  - question: '¿Qué es un endpoint de API?'
    answer: 'La URL específica donde una API recibe solicitudes para un recurso — /users/42 es el endpoint del usuario 42. Endpoint más método definen una operación: GET /users/42 lo lee, DELETE /users/42 lo elimina. Los endpoints son la superficie direccionable de toda la interfaz.'
  - question: '¿Qué es una API key?'
    answer: 'Una cadena generada que el cliente envía con cada request para que el proveedor identifique a quien llama, mida el uso y aplique límites o revocación. Es más identificación que autorización — las APIs de producción añaden autenticación real por encima, como tokens emitidos vía OAuth, para permisos por usuario.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API — MDN Web Docs glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
  - name: 'OpenAPI Specification'
    url: 'https://spec.openapis.org/oas/latest.html'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
    url: 'https://www.rfc-editor.org/rfc/rfc6749'
  - name: 'API — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/API'
cta:
  title: 'Tu backend, ya convertido en API'
  text: 'Define un modelo de datos en Back4app y la plataforma genera las APIs REST y GraphQL por ti — endpoints, auth y permisos incluidos — con SDKs que las hablan de forma idiomática desde cada plataforma principal.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-27'
translationKey: api
---

**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

| Pregunta | Respuesta |
| --- | --- |
| La definición | Un contrato de solicitud/respuesta definido entre dos programas |
| El ciclo | Endpoint + método + headers + cuerpo → código de estado + respuesta |
| Por audiencia | Pública · de socios · interna · compuesta |
| Por estilo | REST · GraphQL · gRPC · SOAP · WebSocket |
| El contrato moderno | Una spec legible por máquinas (OpenAPI) que genera docs, clientes y mocks |

## 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:

```text
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:**

```javascript
// 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
// 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}');
```

**Swift:**

```swift
// 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 ?? "")") }
}
```

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: El ciclo de solicitud y respuesta de una API
  accDescr: Una aplicación cliente envía una solicitud con método, endpoint, headers y cuerpo a una API, que la valida y autoriza, invoca la lógica de backend y los datos, y devuelve un código de estado con un cuerpo de respuesta al cliente.
  C["App cliente<br/>(web, móvil, otro servidor)"] -->|"solicitud:<br/>método + endpoint + headers + cuerpo"| A["API<br/>valida · autoriza · enruta"]
  A --> B["Lógica de backend<br/>+ base de datos"]
  B --> A
  A -->|"respuesta:<br/>código de estado + JSON"| C
```

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](/glossary/data-layer-vs-application-layer-security/) viven en la interfaz, y por eso los clientes hablan con APIs y nunca con [la base de datos](/glossary/nosql-vs-sql/) 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](https://spec.openapis.org/oas/latest.html) 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:**

| Tipo | Consumidores | Preocupaciones típicas |
| --- | --- | --- |
| Pública (abierta) | Cualquier desarrollador registrado | Keys, cuotas, calidad de docs, disciplina de versionado |
| De socios | Empresas bajo contrato | Acuerdos legales, SLAs, auth más estricta |
| Interna (privada) | Tus propios equipos y servicios | Contratos entre microservicios, ciclos de cambio más rápidos |
| Compuesta | Clientes que necesitan paquetes | Una llamada orquesta varias — menos viajes de ida y vuelta |

**Por estilo:** [REST](/glossary/es/api-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](/glossary/websockets-real-time-sync/)) — 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

| Estilo | Formato de cable | Modelo | Su fuerte | Cuidado con |
| --- | --- | --- | --- | --- |
| REST | JSON sobre HTTP | Recursos + métodos | APIs CRUD públicas, cacheabilidad, ubicuidad | Over/underfetching con formas fijas |
| GraphQL | JSON sobre HTTP | Consultas compuestas por el cliente | Clientes diversos, datos anidados | Complejidad de caché, N+1 en resolvers |
| gRPC | Protobuf sobre HTTP/2 | Llamadas a procedimientos tipadas | Velocidad interna servicio a servicio | Fricción en navegadores, debugging binario |
| SOAP | Sobres XML | Operaciones + estándares WS-* | Enterprise legacy, contratos formales | Verbosidad, peso del tooling |
| WebSocket | Frames sobre un socket | Mensajes bidireccionales | Push en tiempo real, presencia | El protocolo lo defines tú |

## 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

| Tu situación | Elige |
| --- | --- |
| CRUD público sobre recursos | REST — la lingua franca, amigable con el caché |
| Muchos tipos de cliente, cada uno con formas distintas | Selection sets de GraphQL |
| Malla interna de servicios de alto throughput | Contratos gRPC |
| Tiempo real, bidireccional, siempre conectado | WebSocket (o una capa de live queries encima) |
| Socio enterprise con requisitos WS-* | SOAP — porque el contrato lo dice |
| Una pantalla que necesita cinco servicios | Un endpoint compuesto o backend-for-frontend |

## 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](/glossary/api-rate-limiting-throttling/) 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](https://www.rfc-editor.org/rfc/rfc6749), 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](/glossary/overfetching-underfetching/).

## 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](/glossary/es/apis-generadas-automaticamente/) — 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](/glossary/backend-sdk/) 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.