El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Conèixer la història de les APIs no és un exercici de nostàlgia: és la manera més ràpida d'entendre per què REST és com és. Cada decisió que avui ens sembla òbvia —fer servir HTTP, retornar JSON, identificar recursos amb adreces— va ser la resposta a un problema concret que les tecnologies anteriors no van saber resoldre. Aquesta lliçó recorre aquest camí des de les crides a procediment remot dels anys vuitanta fins a l'ecosistema actual d'API-first, gateways i microserveis, i acaba extraient les lliçons pràctiques que serveixen a qui dissenya una API avui, inclosa la Botiga Aroma.

Contingut

El punt de partida: cridar codi que és en una altra màquina
RPC, CORBA i DCOM: l'era de l'acoblament fort
El web i HTTP com a substrat universal
XML-RPC, SOAP i la pila WS-*
Roy Fielding i el naixement de REST (2000)
L'auge de les APIs públiques i l'economia de les APIs
De XML a JSON
El mòbil com a accelerador
L'era actual: API-first, OpenAPI, gateways i microserveis
GraphQL i gRPC: respostes a límits concrets de REST
Quines lliçons deixa aquesta història (i per què la Botiga Aroma tria REST)

El punt de partida: cridar codi que és en una altra màquina

Durant dècades, un programa era una única peça que s'executava en un sol ordinador. Quan van aparèixer les xarxes, va sorgir una necessitat evident: que un programa pogués fer servir funcions que resideixen en una altra màquina. I amb ella, la pregunta que ha guiat 40 anys de tecnologia:

Com faig que cridar alguna cosa remota s'assembli al màxim possible a cridar una funció local?

Aquesta pregunta, formulada així, va resultar ser un parany. Una crida local és instantània, fiable i no falla per causes alienes al programa. Una crida remota triga mil·lisegons o segons, es pot perdre, pot arribar dues vegades i es pot quedar esperant per sempre. Els vuit cèlebres "errors de la computació distribuïda" (la xarxa és fiable, la latència és zero, l'amplada de banda és infinita, la xarxa és segura...) descriuen exactament les suposicions que fallen. Bona part de la història que segueix consisteix a aprendre aquesta lliçó una vegada i una altra.

RPC, CORBA i DCOM: l'era de l'acoblament fort

La primera resposta va ser RPC (Remote Procedure Call, crida a procediment remot), popularitzat per Sun als anys vuitanta. La idea: el desenvolupador escriu obtenirCafe(1) i una capa intermèdia (l'stub) empaqueta la crida, l'envia per la xarxa, la desempaqueta al servidor, executa la funció real i en retorna el resultat.

Als noranta van aparèixer versions més ambicioses i orientades a objectes:

CORBA (Common Object Request Broker Architecture), del consorci OMG: multiplataforma i multillenguatge, amb un llenguatge de definició d'interfícies (IDL) i un intermediari (ORB).
DCOM, la proposta de Microsoft, integrada al món Windows.
RMI, la proposta específica de Java.

Funcionaven, i en entorns controlats funcionaven bé. Però acumulaven problemes seriosos:

Problema	Conseqüència pràctica
Acoblament fort entre client i servidor	Canviar una interfície obligava a regenerar i tornar a desplegar tots els clients alhora
Protocols binaris propietaris	Els tallafocs els bloquejaven; travessar internet era un malson
Dependència de plataforma o proveïdor	DCOM lligava a Windows; els ORB de CORBA de fabricants diferents no sempre s'entenien
Estat al servidor	Es desaven referències a objectes remots vius, cosa que dificultava escalar i sobreviure a caigudes
Complexitat	Corba d'aprenentatge alta i eines pesants
La il·lusió de la transparència	Com que semblaven crides locals, s'escrivia codi que feia centenars de crides remotes sense adonar-se'n

La lliçó que en va quedar: amagar la xarxa no l'elimina. Un disseny remot ha de reconèixer explícitament que hi ha latència i fallades.

El web i HTTP com a substrat universal

Mentrestant, en paral·lel, passava una cosa aparentment sense relació: Tim Berners-Lee inventava la World Wide Web (1989-1991) amb tres peces —URL, HTTP i HTML— pensades per compartir documents entre científics.

El web tenia propietats que als sistemes distribuïts empresarials els faltaven:

Un espai de noms universal: qualsevol cosa es podia identificar amb una URL.
Un protocol simple i textual que travessava tallafocs perquè tothom deixava passar el port 80.
Sense estat, cosa que va permetre escalar a milions d'usuaris i afegir-hi memòries cau intermèdies.
Independent de llenguatge i plataforma: només calia saber parlar text per un sòcol.

A finals dels noranta la conclusió es va tornar difícil d'ignorar: el web havia escalat a escala planetària amb un model molt més simple que CORBA. I si en comptes d'inventar un transport nou, es feia servir el que ja funcionava?

XML-RPC, SOAP i la pila WS-*

La primera resposta a aquesta pregunta va ser, curiosament, tornar a fer RPC però damunt d'HTTP i amb XML. El 1998 va aparèixer XML-RPC: crides a procediment serialitzades en XML i enviades per POST. Senzill i llegible.

D'aquí va evolucionar SOAP (Simple Object Access Protocol), impulsat per Microsoft i IBM i estandarditzat després pel W3C, i amb ell tota la família de "serveis web": WSDL per descriure el contracte de manera llegible per màquines, UDDI per descobrir serveis i la pila WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction) per afegir-hi seguretat, fiabilitat i transaccions.

SOAP va resoldre coses reals: un contracte formal verificable, generació automàtica de codi client, seguretat a nivell de missatge i neutralitat de transport. Però la pila va créixer tant que es va tornar pesant: missatges XML verbosos, especificacions enormes, dependència total de les eines i una implementació difícil sense un IDE que ho generés tot. Compararem tots dos enfocaments en detall a la lliçó 01-06.

La conseqüència important per a la nostra història és que SOAP feia servir HTTP com a simple túnel: tot anava per POST a un únic endpoint, i s'ignoraven els mètodes, els codis d'estat i la memòria cau del protocol. Algú havia d'assenyalar que allò era malgastar el web.

Roy Fielding i el naixement de REST (2000)

L'any 2000, Roy Fielding —coautor de l'especificació d'HTTP/1.1— va publicar la seva tesi doctoral Architectural Styles and the Design of Network-based Software Architectures. El capítol 5 descriu REST (Representational State Transfer).

L'important de la tesi és el seu mètode: Fielding no va inventar una tecnologia, sinó que va descriure per què el web funcionava. Va analitzar les propietats desitjables d'un sistema distribuït a escala d'internet (escalabilitat, evolució independent, visibilitat, portabilitat) i en va derivar un conjunt de restriccions arquitectòniques que les produeixen: client-servidor, sense estat, memòria cau, interfície uniforme, sistema en capes i codi sota demanda.

Dos matisos que es malinterpreten constantment i que convé fixar des d'ara:

REST no és un protocol ni un estàndard: és un estil arquitectònic. No hi ha cap especificació de "REST" que es pugui validar.
REST no vol dir "JSON sobre HTTP". Moltes APIs anomenades REST no compleixen diverses de les seves restriccions.

Desenvoluparem les restriccions una a una a la lliçó 01-04, i a 01-05 veurem una eina per mesurar com de a prop és una API real del model.

Durant els primers anys, REST va ser una idea acadèmica amb pocs seguidors. El que la va convertir en dominant va ser el que passava en paral·lel al món comercial.

L'auge de les APIs públiques i l'economia de les APIs

A començament dels 2000, diverses empreses van descobrir que exposar els seus serveis a tercers els multiplicava l'abast:

Any	Fita	Per què va importar
2000	Salesforce llança la seva API en XML	Primera gran empresa que neix amb l'API com a part del producte
2000	eBay obre la seva API	Permet a eines externes llistar i gestionar subhastes
2002	Amazon obre la seva API de comerç	Els afiliats venen productes d'Amazon des dels seus webs
2004	Flickr publica la seva API	Motor dels mashups: combinar serveis de diversos proveïdors
2006	Amazon Web Services (S3, EC2)	La infraestructura mateixa passa a consumir-se per API
2006	Twitter i Facebook obren les seves APIs	Ecosistemes sencers d'aplicacions de tercers

Un episodi il·lustratiu: quan Amazon va oferir tots dos estils, la immensa majoria del trànsit de desenvolupadors va acabar fent servir la variant REST en comptes de la SOAP, senzillament perquè es podia provar amb el navegador i no requeria eines especials. La simplicitat va guanyar per adopció, no per decret.

D'aquí neix l'expressió "economia de les APIs": l'API deixa de ser un detall tècnic i es converteix en un canal de negoci. També es va popularitzar l'anomenat "mandat de Bezos" (2002), la directriu interna d'Amazon segons la qual tots els equips havien d'exposar les seves dades i funcions exclusivament a través d'interfícies de servei, sense excepcions. Aquest principi —comunicar-se només per interfícies ben definides— és el germen cultural dels microserveis.

Per a la Botiga Aroma això es tradueix en una cosa molt concreta: publicar el catàleg per API no és només un caprici tècnic, és permetre que comparadors i blogs de cafè generin trànsit i vendes.

De XML a JSON

Al principi, gairebé totes les APIs retornaven XML. Comparem la mateixa informació en tots dos formats.

En XML, tal com es veia el 2004:

<?xml version="1.0" encoding="UTF-8"?>
<cafe>
  <id>caf_001</id>
  <nom>Etiòpia Yirgacheffe</nom>
  <origen>Etiòpia</origen>
  <torrefaccio>clar</torrefaccio>
  <preuEuros>14.50</preuEuros>
  <estoc>120</estoc>
</cafe>

En JSON, tal com el retornem avui:

{
  "id": "caf_001",
  "nom": "Etiòpia Yirgacheffe",
  "origen": "Etiòpia",
  "torrefaccio": "clar",
  "preuEuros": 14.50,
  "estoc": 120
}

El segon ocupa aproximadament la meitat i, sobretot, en un navegador ja és un objecte utilitzable:

// Consumir JSON des del navegador: dues línies i cap analitzador addicional.
const resposta = await fetch('https://api.botigaaroma.example/v1/cafes/caf_001');
const cafe = await resposta.json();    // JSON -> objecte JavaScript
console.log(cafe.preuEuros);           // 14.5

// Amb XML hauria calgut recórrer un arbre DOM:
// document.getElementsByTagName('preuEuros')[0].textContent -> "14.50" (text, no nombre)

JSON va ser formalitzat per Douglas Crockford a partir del 2001 i estandarditzat després (ECMA-404, RFC 8259). Es va imposar perquè:

És més compacte, cosa que importa en xarxes mòbils.
Encaixa de manera natural amb els tipus de dades dels llenguatges moderns.
És més fàcil de llegir per a un humà que depura.
No necessita el pesat aparell d'esquemes i espais de noms d'XML (encara que existeix JSON Schema quan cal validar, com veurem a 03-04).

XML no va desaparèixer: continua viu allà on la validació estricta, la signatura digital o els documents mixtos són requisits, i en molts sistemes del sector financer i sanitari.

El mòbil com a accelerador

L'arribada de l'iPhone (2007) i l'App Store (2008) va canviar les prioritats de cop. Les aplicacions mòbils necessitaven un backend, i aquest backend va ser una API web. Aquest canvi va imposar restriccions que van empènyer encara més cap a REST + JSON:

Amplada de banda limitada i cara: cada byte compta, i XML pesava.
Latència alta: minimitzar el nombre d'anades i tornades esdevé crític. D'aquí naixerà més tard la crítica a l'over-fetching que motiva GraphQL.
Bateria: menys ràdio encesa, menys consum.
Múltiples clients sobre la mateixa API: web, iOS i Android compartint backend.
Versions antigues eternes: l'usuari decideix quan actualitza l'app, així que l'API ha de continuar servint clients de fa dos anys. Aquest punt, més que cap altre, va convertir el versionat (lliçó 02-07) en una disciplina obligatòria.

L'era actual: API-first, OpenAPI, gateways i microserveis

A la dècada del 2010 l'ecosistema va madurar i van aparèixer quatre idees que avui donem per descomptades:

API-first: l'API es dissenya abans d'implementar-la, es revisa amb els seus consumidors i s'acorda com a contracte. El codi ve després. És el contrari de "exposem el que surti del model de dades".
OpenAPI (abans Swagger): un format estàndard per descriure una API REST de manera llegible per màquines. D'aquesta descripció en surten documentació navegable, clients generats, servidors simulats i proves automàtiques. És, en certa manera, el WSDL que REST no tenia, però opcional i molt més lleuger. Hi treballarem a 05-02.
API gateways i portals de desenvolupador: una capa davant de l'API que centralitza autenticació, límits d'ús, mètriques i encaminament, i un portal on els consumidors es registren i obtenen credencials (lliçó 05-06).
Microserveis: descompondre una aplicació gran en serveis petits que es comuniquen per API. Va multiplicar el nombre d'APIs d'una empresa: no només les públiques, sinó desenes d'internes.

GraphQL i gRPC: respostes a límits concrets de REST

A mitjan dècada va quedar clar que REST, tot i ser excel·lent, no ho resolia tot igual de bé. Van aparèixer dues alternatives, cadascuna atacant una limitació diferent:

GraphQL (Facebook, 2015): neix del problema mòbil de demanar dades a mida. En una API REST, mostrar la pantalla d'una comanda pot requerir tres o quatre peticions, i cadascuna retorna més camps dels necessaris. GraphQL permet al client demanar exactament els camps que vol en una sola consulta.
gRPC (Google, 2015): és RPC un altre cop, però ben fet per a l'era moderna: contracte explícit en un fitxer .proto, serialització binària compacta amb Protocol Buffers, HTTP/2 i streaming. El seu terreny natural és la comunicació entre serveis interns, on el rendiment importa més que l'accessibilitat des d'un navegador.

És interessant notar que gRPC tanca el cercle: tornem a RPC, però amb les lliçons apreses (contracte explícit, transport estàndard, sense il·lusió de transparència). Els compararem tots dos amb REST, juntament amb els webhooks, a la lliçó 01-07.

graph LR
    A["1980s<br/>RPC<br/><i>crides remotes</i>"] --> B["1990s<br/>CORBA · DCOM · RMI<br/><i>acoblament fort</i>"]
    B --> C["1991-1998<br/>Web + XML-RPC<br/><i>HTTP com a substrat</i>"]
    C --> D["1999-2005<br/>SOAP i WS-*<br/><i>contracte i pila pesant</i>"]
    D --> E["2000<br/>REST (Fielding)<br/><i>estil arquitectònic</i>"]
    E --> F["2000-2008<br/>APIs públiques + JSON<br/><i>economia de les APIs</i>"]
    F --> G["2008-2015<br/>Mòbil i OpenAPI<br/><i>contracte lleuger</i>"]
    G --> H["2015-avui<br/>GraphQL · gRPC · esdeveniments<br/><i>API-first i microserveis</i>"]

Quines lliçons deixa aquesta història (i per què la Botiga Aroma tria REST)

De tot el recorregut se'n poden extreure cinc lliçons aplicables a qualsevol API que dissenyis avui:

La interoperabilitat guanya a l'elegància. Les tecnologies que van triomfar van ser les que funcionaven des de qualsevol llenguatge, plataforma i xarxa, encara que tècnicament hi hagués opcions més sofisticades.
La simplicitat s'adopta; la complexitat s'abandona. SOAP era més complet que REST i va perdre quota al web públic. Si un desenvolupador pot provar la teva API amb curl en trenta segons, la farà servir.
La xarxa no es pot amagar. Tot intent de fingir que una crida remota és local acaba malament. Dissenya assumint latència, fallades i reintents.
Tota API ha de poder evolucionar. Les que sobreviuen són les que poden afegir coses sense trencar els clients existents. L'acoblament fort de CORBA va ser la seva condemna.
No hi ha una sola resposta correcta. Les tecnologies conviuen: avui és normal tenir REST cap a fora, gRPC entre serveis i esdeveniments per a allò asíncron.

La decisió de la Botiga Aroma el 2026

Amb aquest context, l'elecció de l'equip de la Botiga Aroma s'entén tota sola:

Necessitat	Decisió	Motiu històric
API pública de catàleg per a blogs i comparadors	REST + JSON	Màxima interoperabilitat i barrera d'entrada mínima; es prova des del navegador
Web, app mòbil i panell intern sobre el mateix backend	REST versionat	Un contracte estable que sobreviu a apps mòbils antigues
Aprofitar memòries cau i infraestructura estàndard	REST sobre HTTP	Mètodes, codis i memòria cau natius del protocol, sense inventar res
Comunicació entre els seus propis serveis interns	gRPC (ho veurem a 01-07)	Rendiment i contracte fort allà on controles tots dos extrems
Avisar RàpidEnviaments d'una comanda pagada	Webhooks	L'avís ha de sortir del servidor cap a fora, no esperar que preguntin

Errors Comuns i Consells

Creure que REST va "substituir" SOAP a tot arreu. SOAP continua viu a la banca, les assegurances i la sanitat. Veuràs façanes REST muntades sobre serveis SOAP heretats durant molts anys més.
Interpretar GraphQL o gRPC com "la versió següent de REST". No en són successors, són eines per a problemes diferents. Triar per novetat és la pitjor de les raons.
Repetir l'error de CORBA amb noms moderns. Si la teva API interna obliga a desplegar client i servidor alhora, has reintroduït l'acoblament fort, facis servir la tecnologia que facis servir.
Dissenyar l'API a partir del model de dades. L'enfocament API-first existeix precisament perquè exposar les taules produeix contractes impossibles de mantenir.
Consell: quan algú et proposi una tecnologia d'integració, pregunta-li quin problema concret resol en el teu context. Tota aquesta història és una successió de solucions que van ser excel·lents per al seu problema i desastroses fora d'ell.

Exercicis

Exercici 1: del problema a la tecnologia

Relaciona cada problema històric amb la solució que el va abordar i explica en una frase el vincle:

Problemes: (a) els protocols binaris no travessen tallafocs; (b) XML pesa massa per a xarxes mòbils; (c) no hi ha manera automàtica de generar clients per a una API REST; (d) el client mòbil necessita fer quatre peticions per pintar una pantalla.

Solucions: OpenAPI, JSON, GraphQL, HTTP com a transport.

Exercici 2: justificar una decisió d'arquitectura

La Botiga Aroma vol que el seu proveïdor de torrefacció (una empresa externa, amb sistemes antics basats en Windows) rebi automàticament les ordres de producció. Un company proposa exposar objectes remots amb DCOM perquè "així criden els nostres mètodes directament". Escriu una resposta raonada amb tres arguments històrics en contra i una proposta alternativa.

Exercici 3: traduir XML a JSON amb criteri

Aquest és el fragment que retorna un sistema heretat de la Botiga Aroma. Converteix-lo en una resposta JSON moderna aplicant-hi el que has après en aquesta lliçó i en l'anterior (noms clars, unitats explícites, tipus correctes, embolcall adequat).

<comandes>
  <comanda num="5001" client="842">
    <data>14/07/2026</data>
    <import>29.40</import>
    <estat>P</estat>
  </comanda>
</comandes>

Solucions

Solució 1

(a) HTTP com a transport: en viatjar pel port 80/443 en text, les peticions travessen tallafocs i servidors intermediaris que bloquejaven CORBA i DCOM.
(b) JSON: format molt més compacte i directament utilitzable pel client, clau amb l'explosió mòbil.
(c) OpenAPI: descriu l'API de manera llegible per màquines, i permet generar documentació, clients i simuladors, que era el principal avantatge que SOAP tenia amb WSDL.
(d) GraphQL: permet demanar en una sola consulta exactament els camps de diversos recursos, i ataca l'under-fetching i l'over-fetching.

Solució 2

Tres arguments històrics:

Acoblament fort: amb objectes remots, qualsevol canvi d'interfície obliga a coordinar desplegaments amb una empresa externa sobre la qual no tenim cap control. És exactament la fallada que va enfonsar CORBA i DCOM.
Travessar la xarxa: DCOM fa servir ports dinàmics i protocols binaris que els tallafocs corporatius bloquegen; integrar dues empreses per internet amb aquesta base és una font permanent d'incidències.
Dependència de plataforma i proveïdor: DCOM lliga totes dues parts a Windows per sempre i limita les opcions tecnològiques futures de la Botiga Aroma.

Alternativa: exposar una API REST de socis amb autenticació per credencials del proveïdor i, per a l'avís en temps real, un webhook que notifiqui el proveïdor quan hi hagi una nova ordre de producció. Si el proveïdor no pot rebre webhooks (els sistemes antics sovint no poden), se li ofereix l'opció de consultar periòdicament un recurs d'ordres pendents.

Solució 3

{
  "dades": [
    {
      "id": "com_5001",
      "clientId": "cli_842",
      "dataCreacio": "2026-07-14",
      "totalEuros": 29.40,
      "estat": "pagat"
    }
  ],
  "total": 1
}

Millores aplicades:

La data passa a format ISO 8601 (2026-07-14), inequívoc davant de 14/07/2026.
import es converteix en totalEuros, amb la unitat explícita al nom.
El codi críptic P passa a un valor llegible i de conjunt tancat (pagat); un consumidor extern no té per què conèixer la teva taula de codis interns.
Els identificadors porten prefix (com_, cli_) i són cadenes, no nombres, cosa que evita zeros a l'esquerra perduts i facilita canviar d'esquema.
La llista s'embolcalla dins de dades amb un total, i deixa espai per a metadades de paginació (lliçó 02-06).

Conclusió

La història de les APIs és la història d'un mateix problema —fer que dos sistemes s'entenguin— resolt successivament amb RPC, objectes distribuïts, serveis web SOAP i, finalment, REST sobre HTTP amb JSON. Cada etapa va deixar una lliçó: la xarxa no es pot amagar, l'acoblament fort es paga, la interoperabilitat i la simplicitat són les que determinen l'adopció, i tota API ha de poder evolucionar sense trencar els seus consumidors. Avui conviuen REST, GraphQL, gRPC i la comunicació per esdeveniments, i la Botiga Aroma els combinarà segons el cas: REST cap a fora, gRPC cap a dins i webhooks per a integracions.

Abans d'estudiar REST pròpiament, necessitem dominar el terreny sobre el qual s'assenta. A la lliçó següent, Fonaments d'HTTP per a APIs, obrirem el protocol en canal: l'anatomia exacta d'una petició i una resposta, què vol dir que HTTP sigui sense estat, les parts d'una URL, les capçaleres més habituals i per què tota API ha de viatjar xifrada.

Història i evolució de les APIs