REST vs GraphQL: quina és la diferència i quin hauries d'usar?

REST i GraphQL són dues maneres de dissenyar una API: la manera acordada perquè les pantalles de la teva aplicació (o altres programes) demanin dades al teu backend. Amb REST, hi ha una URL diferent per a cada tipus d'element, com /customers o /orders, i cadascuna retorna una forma de dades fixa. Amb GraphQL, normalment hi ha una sola URL, i qui fa la petició envia una consulta que enumera exactament els camps que vol rebre. Per a la majoria d'aplicacions creades amb IA, REST és l'opció més senzilla i la més adequada per defecte.

Per què importa quan construeixes amb IA

Quan demanes a un creador amb IA «una aplicació amb backend», ha de decidir com parlen el frontend i el backend. No cal que ho decideixis cada vegada, però veuràs aquests termes al codi, a la documentació i quan et connectes a serveis externs. Alguns serveis només ofereixen un estil: molts serveis exposen API REST, mentre que d'altres, com Shopify i GitHub, també ofereixen o prefereixen GraphQL. Conèixer la diferència t'ajuda a entendre el que tens davant i a evitar afegir complexitat que no necessites. Si «API» és nou per a tu, comença per què és una API.

Una analogia de la vida quotidiana

REST és un menú fix d'un restaurant. Cada plat (endpoint) arriba tal com el va dissenyar la cuina. Si demanes el plat «client», reps tot el plat —nom, correu electrònic, adreça, data de registre—, encara que només volguessis el nom. Si també vols les seves comandes recents, és un altre plat.

GraphQL és demanar a la carta a un mateix cambrer. Escrius exactament el que vols: «el nom del client i les dates i els imports de les seves tres últimes comandes». Una comanda, un plat, només el que has demanat. Però la cuina ha d'estar preparada per gestionar qualsevol combinació que els clients puguin escriure.

La mateixa petició, de les dues maneres

Suposem que una pàgina de client necessita el nom d'un client i les seves tres comandes més recents.

Amb REST, normalment són dues peticions:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

La primera resposta podria incloure més del que necessita la pàgina:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Amb GraphQL, és una sola petició, normalment un POST a un únic endpoint com /graphql, amb una consulta:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

I la resposta reflecteix exactament la consulta:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Totes dues retornen JSON. La diferència és qui decideix la forma: en REST, ho decideix el servidor; en GraphQL, ho decideix qui fa la petició, dins del que permet l'esquema del servidor.

Comparació directa

On encaixa cadascun

Tria REST quan:

• Construeixes una aplicació típica: un sistema de reserves, un CRM, un tauler de control, una botiga.
• Un frontend parla amb un backend, i tu controles tots dos.
• Vols la solució més senzilla per depurar, emmagatzemar a la memòria cau i protegir.
• Altres serveis cridaran la teva aplicació (els webhooks i la majoria d'integracions esperen endpoints d'estil REST).

Considera GraphQL quan:

• Diversos clients diferents —un lloc web, una aplicació mòbil, integracions amb socis— necessiten fragments molt diferents de les mateixes dades.
• Les teves dades estan molt connectades (productes, variants, ressenyes, venedors, inventari) i les pantalles les han de combinar de moltes maneres.
• Consumeixes un servei que ofereix GraphQL com a API principal.

Una regla útil: si no estàs segur que necessitis GraphQL, probablement encara no el necessites. És més fàcil afegir-lo més tard que treure'l.

Termes clau

Idees errònies habituals

• «GraphQL és més nou, així que és millor». Resol problemes concrets. Per a una sola aplicació amb un sol frontend, sovint afegeix feina sense gaires beneficis.
• «GraphQL és una base de dades». No ho és. És una capa d'API; per sota, el servidor continua llegint de la teva base de dades.
• «GraphQL és sempre més ràpid». Menys peticions poden ajudar amb xarxes mòbils lentes, però una consulta sense límits pot carregar quantitats enormes de dades. El rendiment depèn del backend.
• «REST vol dir un estàndard estricte». A la pràctica, «API REST» vol dir de manera laxa URL de recursos, mètodes HTTP i JSON. Moltes bones API es salten les regles formals.
• «Estat 200 vol dir que ha funcionat». Amb GraphQL, revisa el camp errors: una petició pot fallar parcialment i tot i així retornar 200.

Què demanar al teu creador amb IA

• «Fes servir una API REST senzilla amb JSON, tret que hi hagi un motiu clar per no fer-ho. Explica'm si creus que cal GraphQL.»
• «Enumera cada endpoint, què retorna i qui té permís per cridar-lo.»
• «Per a la pàgina de client, retorna només els camps que fa servir la pàgina.»
• «Afegeix paginació als endpoints de llistes perquè mai no retornin milers de files de cop.»
• «Aquest servei només té una API GraphQL: crida'l des del servidor, guarda la clau en un secret i demana només els camps que necessitem.»
• «Retorna codis d'estat HTTP adequats i missatges d'error en JSON.»

REST i GraphQL a Mythex

La documentació de Mythex inclou una recepta per construir un backend d'API REST amb un prompt inicial, i un backend pot funcionar en Node, Python (FastAPI), C# o Java juntament amb la teva aplicació web. La documentació no descriu cap plantilla de GraphQL, així que, si en vols una, demana-la explícitament i explica per què. Cridar una API GraphQL de tercers funciona com qualsevol altre servei extern; consulta integrar qualsevol API. Lectures relacionades: frontend vs backend i com construir una API REST.

Preguntes