El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Conocer la historia de las APIs no es un ejercicio de nostalgia: es la forma más rápida de entender por qué REST es como es. Cada decisión que hoy nos parece obvia —usar HTTP, devolver JSON, identificar recursos con direcciones— fue la respuesta a un problema concreto que las tecnologías anteriores no supieron resolver. Esta lección recorre ese camino desde las llamadas a procedimiento remoto de los años ochenta hasta el ecosistema actual de API-first, gateways y microservicios, y termina extrayendo las lecciones prácticas que le sirven a quien diseña una API hoy, incluida Tienda Aroma.

Contenido

El punto de partida: llamar a código que está en otra máquina
RPC, CORBA y DCOM: la era del acoplamiento fuerte
La web y HTTP como sustrato universal
XML-RPC, SOAP y la pila WS-*
Roy Fielding y el nacimiento de REST (2000)
El auge de las APIs públicas y la economía de las APIs
De XML a JSON
El móvil como acelerador
La era actual: API-first, OpenAPI, gateways y microservicios
GraphQL y gRPC: respuestas a límites concretos de REST
Qué lecciones deja esta historia (y por qué Tienda Aroma elige REST)

El punto de partida: llamar a código que está en otra máquina

Durante décadas, un programa era una única pieza que se ejecutaba en un solo ordenador. Cuando aparecieron las redes, surgió una necesidad evidente: que un programa pudiera usar funciones que residen en otra máquina. Y con ella, la pregunta que ha guiado 40 años de tecnología:

¿Cómo hago que llamar a algo remoto se parezca lo máximo posible a llamar a una función local?

Esa pregunta, formulada así, resultó ser una trampa. Una llamada local es instantánea, fiable y no falla por causas ajenas al programa. Una llamada remota tarda milisegundos o segundos, puede perderse, puede llegar dos veces y puede quedarse esperando para siempre. Los ocho célebres "errores de la computación distribuida" (la red es fiable, la latencia es cero, el ancho de banda es infinito, la red es segura...) describen exactamente las suposiciones que fallan. Buena parte de la historia que sigue consiste en aprender esta lección una y otra vez.

RPC, CORBA y DCOM: la era del acoplamiento fuerte

La primera respuesta fue RPC (Remote Procedure Call, llamada a procedimiento remoto), popularizado por Sun en los años ochenta. La idea: el desarrollador escribe obtenerCafe(1) y una capa intermedia (el stub) empaqueta la llamada, la envía por la red, la desempaqueta en el servidor, ejecuta la función real y devuelve el resultado.

En los noventa aparecieron versiones más ambiciosas y orientadas a objetos:

CORBA (Common Object Request Broker Architecture), del consorcio OMG: multiplataforma y multilenguaje, con un lenguaje de definición de interfaces (IDL) y un intermediario (ORB).
DCOM, la propuesta de Microsoft, integrada en el mundo Windows.
RMI, la propuesta específica de Java.

Funcionaban, y en entornos controlados funcionaban bien. Pero acumulaban problemas serios:

Problema	Consecuencia práctica
Acoplamiento fuerte entre cliente y servidor	Cambiar una interfaz obligaba a regenerar y redesplegar todos los clientes a la vez
Protocolos binarios propietarios	Los cortafuegos los bloqueaban; atravesar internet era una pesadilla
Dependencia de plataforma o proveedor	DCOM ataba a Windows; los ORB de CORBA de distintos fabricantes no siempre se entendían
Estado en el servidor	Se guardaban referencias a objetos remotos vivos, lo que dificultaba escalar y sobrevivir a caídas
Complejidad	Curva de aprendizaje alta y herramientas pesadas
La ilusión de la transparencia	Al parecer llamadas locales, se escribía código que hacía cientos de llamadas remotas sin darse cuenta

La lección que quedó: ocultar la red no la elimina. Un diseño remoto debe reconocer explícitamente que hay latencia y fallos.

La web y HTTP como sustrato universal

Mientras tanto, en paralelo, ocurría algo aparentemente sin relación: Tim Berners-Lee inventaba la World Wide Web (1989-1991) con tres piezas —URL, HTTP y HTML— pensadas para compartir documentos entre científicos.

La web tenía propiedades que a los sistemas distribuidos empresariales les faltaban:

Un espacio de nombres universal: cualquier cosa se podía identificar con una URL.
Un protocolo simple y textual que atravesaba cortafuegos porque todo el mundo dejaba pasar el puerto 80.
Sin estado, lo que permitió escalar a millones de usuarios y añadir cachés intermedias.
Independiente de lenguaje y plataforma: solo hacía falta saber hablar texto por un socket.

A finales de los noventa la conclusión se volvió difícil de ignorar: la web había escalado a escala planetaria con un modelo mucho más simple que CORBA. ¿Y si en lugar de inventar un transporte nuevo, se usara el que ya funcionaba?

XML-RPC, SOAP y la pila WS-*

La primera respuesta a esa pregunta fue, curiosamente, volver a hacer RPC pero encima de HTTP y con XML. En 1998 apareció XML-RPC: llamadas a procedimiento serializadas en XML y enviadas por POST. Sencillo y legible.

De ahí evolucionó SOAP (Simple Object Access Protocol), impulsado por Microsoft e IBM y luego estandarizado por el W3C, y con él toda la familia de "servicios web": WSDL para describir el contrato de forma legible por máquinas, UDDI para descubrir servicios y la pila WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction) para añadir seguridad, fiabilidad y transacciones.

SOAP resolvió cosas reales: un contrato formal verificable, generación automática de código cliente, seguridad a nivel de mensaje y neutralidad de transporte. Pero la pila creció tanto que se volvió pesada: mensajes XML verbosos, especificaciones enormes, dependencia total de las herramientas y una implementación difícil sin un IDE que generase todo. Compararemos ambos enfoques en detalle en la lección 01-06.

La consecuencia importante para nuestra historia es que SOAP usaba HTTP como mero túnel: todo iba por POST a un único endpoint, ignorando los métodos, los códigos de estado y la caché del protocolo. Alguien iba a señalar que eso era desperdiciar la web.

Roy Fielding y el nacimiento de REST (2000)

En el año 2000, Roy Fielding —coautor de la especificación de HTTP/1.1— publicó su tesis doctoral Architectural Styles and the Design of Network-based Software Architectures. Su capítulo 5 describe REST (Representational State Transfer).

Lo importante de la tesis es su método: Fielding no inventó una tecnología, sino que describió por qué la web funcionaba. Analizó las propiedades deseables de un sistema distribuido a escala de internet (escalabilidad, evolución independiente, visibilidad, portabilidad) y derivó un conjunto de restricciones arquitectónicas que las producen: cliente-servidor, sin estado, caché, interfaz uniforme, sistema en capas y código bajo demanda.

Dos matices que se malinterpretan constantemente y que conviene fijar desde ya:

REST no es un protocolo ni un estándar: es un estilo arquitectónico. No hay una especificación de "REST" que validar.
REST no significa "JSON sobre HTTP". Muchas APIs llamadas REST no cumplen varias de sus restricciones.

Desarrollaremos las restricciones una a una en la lección 01-04, y en 01-05 veremos una herramienta para medir cuánto se acerca una API real al modelo.

Durante los primeros años, REST fue una idea académica con pocos seguidores. Lo que la convirtió en dominante fue lo que ocurrió en paralelo en el mundo comercial.

El auge de las APIs públicas y la economía de las APIs

A comienzos de los 2000, varias empresas descubrieron que exponer sus servicios a terceros multiplicaba su alcance:

Año	Hito	Por qué importó
2000	Salesforce lanza su API en XML	Primera gran empresa que nace con la API como parte del producto
2000	eBay abre su API	Permite a herramientas externas listar y gestionar subastas
2002	Amazon abre su API de comercio	Los afiliados venden productos de Amazon desde sus webs
2004	Flickr publica su API	Motor de los mashups: combinar servicios de varios proveedores
2006	Amazon Web Services (S3, EC2)	La infraestructura misma pasa a consumirse por API
2006	Twitter y Facebook abren sus APIs	Ecosistemas enteros de aplicaciones de terceros

Un episodio ilustrativo: cuando Amazon ofreció ambos estilos, la enorme mayoría del tráfico de desarrolladores acabó usando la variante REST en lugar de la SOAP, sencillamente porque se podía probar con el navegador y no requería herramientas especiales. La simplicidad ganó por adopción, no por decreto.

De ahí nace la expresión "economía de las APIs": la API deja de ser un detalle técnico y se convierte en un canal de negocio. Se popularizó también el llamado "mandato de Bezos" (2002), la directriz interna de Amazon según la cual todos los equipos debían exponer sus datos y funciones exclusivamente a través de interfaces de servicio, sin excepciones. Ese principio —comunicarse solo por interfaces bien definidas— es el germen cultural de los microservicios.

Para Tienda Aroma esto se traduce en algo muy concreto: publicar su catálogo por API no es solo un capricho técnico, es permitir que comparadores y blogs de café generen tráfico y ventas.

De XML a JSON

Al principio, casi todas las APIs devolvían XML. Comparemos la misma información en ambos formatos.

En XML, tal como se veía en 2004:

<?xml version="1.0" encoding="UTF-8"?>
<cafe>
  <id>caf_001</id>
  <nombre>Etiopía Yirgacheffe</nombre>
  <origen>Etiopía</origen>
  <tueste>claro</tueste>
  <precioEuros>14.50</precioEuros>
  <stock>120</stock>
</cafe>

En JSON, tal como lo devolvemos hoy:

{
  "id": "caf_001",
  "nombre": "Etiopía Yirgacheffe",
  "origen": "Etiopía",
  "tueste": "claro",
  "precioEuros": 14.50,
  "stock": 120
}

El segundo ocupa aproximadamente la mitad y, sobre todo, en un navegador ya es un objeto utilizable:

// Consumir JSON desde el navegador: dos líneas y ningún parser adicional.
const respuesta = await fetch('https://api.tiendaaroma.example/v1/cafes/caf_001');
const cafe = await respuesta.json();   // JSON -> objeto JavaScript
console.log(cafe.precioEuros);         // 14.5

// Con XML habría hecho falta recorrer un árbol DOM:
// documento.getElementsByTagName('precioEuros')[0].textContent -> "14.50" (texto, no número)

JSON fue formalizado por Douglas Crockford a partir de 2001 y estandarizado después (ECMA-404, RFC 8259). Se impuso porque:

Es más compacto, lo que importa en redes móviles.
Encaja de forma natural con los tipos de datos de los lenguajes modernos.
Es más fácil de leer para un humano que depura.
No necesita el pesado aparato de esquemas y espacios de nombres de XML (aunque existe JSON Schema cuando hace falta validar, como veremos en 03-04).

XML no desapareció: sigue vivo donde la validación estricta, la firma digital o los documentos mixtos son requisitos, y en muchos sistemas del sector financiero y sanitario.

El móvil como acelerador

La llegada del iPhone (2007) y el App Store (2008) cambió las prioridades de golpe. Las aplicaciones móviles necesitaban un backend, y ese backend fue una API web. Este cambio impuso restricciones que empujaron aún más hacia REST + JSON:

Ancho de banda limitado y caro: cada byte cuenta, y XML pesaba.
Latencia alta: minimizar el número de idas y venidas se vuelve crítico. De aquí nacerá más tarde la crítica al over-fetching que motiva GraphQL.
Batería: menos radio encendida, menos consumo.
Múltiples clientes sobre la misma API: web, iOS y Android compartiendo backend.
Versiones antiguas eternas: el usuario decide cuándo actualiza la app, así que la API debe seguir sirviendo a clientes de hace dos años. Este punto, más que ningún otro, convirtió el versionado (lección 02-07) en una disciplina obligatoria.

La era actual: API-first, OpenAPI, gateways y microservicios

En la década de 2010 el ecosistema maduró y aparecieron cuatro ideas que hoy damos por sentadas:

API-first: la API se diseña antes de implementarla, se revisa con sus consumidores y se acuerda como contrato. El código viene después. Es lo contrario de "exponemos lo que salga del modelo de datos".
OpenAPI (antes Swagger): un formato estándar para describir una API REST de manera legible por máquinas. De esa descripción salen documentación navegable, clientes generados, servidores simulados y pruebas automáticas. Es, en cierto modo, el WSDL que REST no tenía, pero opcional y mucho más ligero. Lo trabajaremos en 05-02.
API gateways y portales de desarrollador: una capa delante de la API que centraliza autenticación, límites de uso, métricas y enrutado, y un portal donde los consumidores se registran y obtienen credenciales (lección 05-06).
Microservicios: descomponer una aplicación grande en servicios pequeños que se comunican por API. Multiplicó el número de APIs de una empresa: no solo las públicas, sino decenas de internas.

GraphQL y gRPC: respuestas a límites concretos de REST

A mediados de la década quedó claro que REST, siendo excelente, no resolvía todo igual de bien. Aparecieron dos alternativas, cada una atacando una limitación distinta:

GraphQL (Facebook, 2015): nace del problema móvil de pedir datos a medida. En una API REST, mostrar la pantalla de un pedido puede requerir tres o cuatro peticiones, y cada una devuelve más campos de los necesarios. GraphQL permite al cliente pedir exactamente los campos que quiere en una sola consulta.
gRPC (Google, 2015): es RPC otra vez, pero bien hecho para la era moderna: contrato explícito en un fichero .proto, serialización binaria compacta con Protocol Buffers, HTTP/2 y streaming. Su terreno natural es la comunicación entre servicios internos, donde el rendimiento importa más que la accesibilidad desde un navegador.

Es interesante notar que gRPC cierra el círculo: volvemos a RPC, pero con las lecciones aprendidas (contrato explícito, transporte estándar, sin ilusión de transparencia). Compararemos ambos con REST, junto a los webhooks, en la lección 01-07.

graph LR
    A["1980s<br/>RPC<br/><i>llamadas remotas</i>"] --> B["1990s<br/>CORBA · DCOM · RMI<br/><i>acoplamiento fuerte</i>"]
    B --> C["1991-1998<br/>Web + XML-RPC<br/><i>HTTP como sustrato</i>"]
    C --> D["1999-2005<br/>SOAP y WS-*<br/><i>contrato y pila pesada</i>"]
    D --> E["2000<br/>REST (Fielding)<br/><i>estilo arquitectónico</i>"]
    E --> F["2000-2008<br/>APIs públicas + JSON<br/><i>economía de las APIs</i>"]
    F --> G["2008-2015<br/>Móvil y OpenAPI<br/><i>contrato ligero</i>"]
    G --> H["2015-hoy<br/>GraphQL · gRPC · eventos<br/><i>API-first y microservicios</i>"]

Qué lecciones deja esta historia (y por qué Tienda Aroma elige REST)

De todo el recorrido se pueden extraer cinco lecciones aplicables a cualquier API que diseñes hoy:

La interoperabilidad gana a la elegancia. Las tecnologías que triunfaron fueron las que funcionaban desde cualquier lenguaje, plataforma y red, aunque técnicamente hubiera opciones más sofisticadas.
La simplicidad se adopta; la complejidad se abandona. SOAP era más completo que REST y perdió cuota en la web pública. Si un desarrollador puede probar tu API con curl en treinta segundos, la usará.
La red no se puede ocultar. Todo intento de fingir que una llamada remota es local acaba mal. Diseña asumiendo latencia, fallos y reintentos.
Toda API debe poder evolucionar. Las que sobreviven son las que pueden añadir cosas sin romper a los clientes existentes. El acoplamiento fuerte de CORBA fue su condena.
No hay una sola respuesta correcta. Las tecnologías conviven: hoy es normal tener REST hacia fuera, gRPC entre servicios y eventos para lo asíncrono.

La decisión de Tienda Aroma en 2026

Con este contexto, la elección del equipo de Tienda Aroma se entiende sola:

Necesidad	Decisión	Motivo histórico
API pública de catálogo para blogs y comparadores	REST + JSON	Máxima interoperabilidad y barrera de entrada mínima; se prueba desde el navegador
Web, app móvil y panel interno sobre el mismo backend	REST versionado	Un contrato estable que sobrevive a apps móviles antiguas
Aprovechar cachés e infraestructura estándar	REST sobre HTTP	Métodos, códigos y caché nativos del protocolo, sin inventar nada
Comunicación entre sus propios servicios internos	gRPC (lo veremos en 01-07)	Rendimiento y contrato fuerte donde controlas ambos extremos
Avisar a RápidoEnvíos de un pedido pagado	Webhooks	El aviso debe salir del servidor hacia fuera, no esperar a que pregunten

Errores Comunes y Consejos

Creer que REST "sustituyó" a SOAP en todas partes. SOAP sigue vivo en banca, seguros y sanidad. Verás fachadas REST montadas sobre servicios SOAP heredados durante muchos años más.
Interpretar GraphQL o gRPC como "la siguiente versión de REST". No son sucesores, son herramientas para problemas distintos. Elegir por novedad es la peor de las razones.
Repetir el error de CORBA con nombres modernos. Si tu API interna obliga a desplegar cliente y servidor a la vez, has reintroducido el acoplamiento fuerte, uses la tecnología que uses.
Diseñar la API a partir del modelo de datos. El enfoque API-first existe precisamente porque exponer las tablas produce contratos imposibles de mantener.
Consejo: cuando alguien te proponga una tecnología de integración, pregunta qué problema concreto resuelve en tu contexto. Toda esta historia es una sucesión de soluciones que fueron excelentes para su problema y desastrosas fuera de él.

Ejercicios

Ejercicio 1: del problema a la tecnología

Relaciona cada problema histórico con la solución que lo abordó y explica en una frase el vínculo:

Problemas: (a) los protocolos binarios no atraviesan cortafuegos; (b) XML pesa demasiado para redes móviles; (c) no hay forma automática de generar clientes para una API REST; (d) el cliente móvil necesita hacer cuatro peticiones para pintar una pantalla.

Soluciones: OpenAPI, JSON, GraphQL, HTTP como transporte.

Ejercicio 2: justificar una decisión de arquitectura

Tienda Aroma quiere que su proveedor de tostado (una empresa externa, con sistemas antiguos basados en Windows) reciba automáticamente las órdenes de producción. Un compañero propone exponer objetos remotos con DCOM porque "así llaman a nuestros métodos directamente". Escribe una respuesta razonada con tres argumentos históricos en contra y una propuesta alternativa.

Ejercicio 3: traducir XML a JSON con criterio

Este es el fragmento que devuelve un sistema heredado de Tienda Aroma. Conviértelo a una respuesta JSON moderna aplicando lo aprendido en esta lección y en la anterior (nombres claros, unidades explícitas, tipos correctos, envoltorio adecuado).

<pedidos>
  <pedido num="5001" cliente="842">
    <fecha>14/07/2026</fecha>
    <importe>29.40</importe>
    <estado>P</estado>
  </pedido>
</pedidos>

Soluciones

Solución 1

(a) HTTP como transporte: al viajar por el puerto 80/443 en texto, las peticiones atraviesan cortafuegos y proxys que bloqueaban CORBA y DCOM.
(b) JSON: formato mucho más compacto y directamente utilizable por el cliente, clave con la explosión móvil.
(c) OpenAPI: describe la API de forma legible por máquinas, permitiendo generar documentación, clientes y simuladores, que era la principal ventaja que SOAP tenía con WSDL.
(d) GraphQL: permite pedir en una sola consulta exactamente los campos de varios recursos, atacando el under-fetching y el over-fetching.

Solución 2

Tres argumentos históricos:

Acoplamiento fuerte: con objetos remotos, cualquier cambio de interfaz obliga a coordinar despliegues con una empresa externa sobre la que no tenemos control. Es exactamente el fallo que hundió a CORBA y DCOM.
Atravesar la red: DCOM usa puertos dinámicos y protocolos binarios que los cortafuegos corporativos bloquean; integrar dos empresas por internet con esa base es una fuente permanente de incidencias.
Dependencia de plataforma y proveedor: DCOM ata a Windows a ambas partes para siempre y limita las opciones tecnológicas futuras de Tienda Aroma.

Alternativa: exponer una API REST de socios con autenticación por credenciales del proveedor y, para el aviso en tiempo real, un webhook que notifique al proveedor cuando haya una nueva orden de producción. Si el proveedor no puede recibir webhooks (sistemas antiguos suelen no poder), se ofrece la opción de que consulte periódicamente un recurso de órdenes pendientes.

Solución 3

{
  "datos": [
    {
      "id": "ped_5001",
      "clienteId": "cli_842",
      "fechaCreacion": "2026-07-14",
      "totalEuros": 29.40,
      "estado": "pagado"
    }
  ],
  "total": 1
}

Mejoras aplicadas:

La fecha pasa a formato ISO 8601 (2026-07-14), inequívoco frente a 14/07/2026.
importe se convierte en totalEuros, con la unidad explícita en el nombre.
El código críptico P pasa a un valor legible y de conjunto cerrado (pagado); un consumidor externo no tiene por qué conocer tu tabla de códigos internos.
Los identificadores llevan prefijo (ped_, cli_) y son cadenas, no números, lo que evita ceros a la izquierda perdidos y facilita cambiar de esquema.
La lista se envuelve en datos con un total, dejando sitio para metadatos de paginación (lección 02-06).

Conclusión

La historia de las APIs es la historia de un mismo problema —hacer que dos sistemas se entiendan— resuelto sucesivamente con RPC, objetos distribuidos, servicios web SOAP y, finalmente, REST sobre HTTP con JSON. Cada etapa dejó una lección: la red no se puede ocultar, el acoplamiento fuerte se paga, la interoperabilidad y la simplicidad son las que determinan la adopción, y toda API debe poder evolucionar sin romper a sus consumidores. Hoy conviven REST, GraphQL, gRPC y la comunicación por eventos, y Tienda Aroma los combinará según el caso: REST hacia fuera, gRPC hacia dentro y webhooks para integraciones.

Antes de estudiar REST propiamente, necesitamos dominar el terreno sobre el que se apoya. En la siguiente lección, Fundamentos de HTTP para APIs, abriremos el protocolo en canal: la anatomía exacta de una petición y una respuesta, qué significa que HTTP sea sin estado, las partes de una URL, las cabeceras más habituales y por qué toda API debe viajar cifrada.

Historia y evolución de las APIs