REST vs GraphQL: mi a különbség, és melyiket használd?

A REST és a GraphQL az API tervezésének két módja: az egyeztetett módja annak, ahogy az app képernyői (vagy más programok) adatot kérnek a backendtől. A REST esetén minden típushoz külön URL tartozik, például /customers vagy /orders, és mindegyik rögzített adatszerkezetet ad vissza. A GraphQL esetén általában egy URL van, a hívó pedig lekérdezést küld, amely pontosan megadja, mely mezőket szeretné visszakapni. AI-val épített appok többségénél a REST az egyszerűbb és jobb alapértelmezés.

Miért számít ez AI-val való építésnél

Amikor egy AI-építőtől „backenddel rendelkező appot” kérsz, el kell döntenie, hogyan kommunikál a frontend a backenddel. Ezt nem neked kell minden alkalommal eldöntened, de a kifejezésekkel találkozni fogsz a kódban, a dokumentációban és külső szolgáltatások csatlakoztatásakor. Vannak szolgáltatások, amelyek csak egyféle stílust kínálnak: sok szolgáltatás REST API-t tesz elérhetővé, mások, például a Shopify és a GitHub, a GraphQL-t is kínálják, vagy azt részesítik előnyben. A különbség ismerete segít megérteni, amit látsz, és elkerülni a fölösleges bonyolultságot. Ha az „API” fogalma új neked, kezdd azzal, mi az API.

Mindennapi hasonlat

A REST egy étterem fix menüje. Minden étel (végpont) úgy érkezik, ahogy a konyha összeállította. Rendeled az „ügyfél” tételt, és megkapod az egész tányért: nevet, e-mailt, címet, regisztrációs dátumot, akkor is, ha csak a nevet akartad. Az ügyfél legutóbbi rendeléseit is kéred? Az egy második tétel.

A GraphQL egy pincértől rendelt à la carte étlap. Leírod pontosan, mit szeretnél: „az ügyfél neve, és az utolsó három rendelésének dátuma és összege”. Egy rendelés, egy tányér, csak azt, amit kértél. Ehhez azonban a konyhát fel kell készíteni arra, hogy bármilyen kombinációt kezeljen, amit a vendégek leírhatnak.

Ugyanaz a kérés, mindkét módon

Tegyük fel, hogy egy ügyféloldalnak egy ügyfél nevére és a legutóbbi három rendelésére van szüksége.

REST-tel ez jellemzően két kérés:

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

Az első válasz többet tartalmazhat, mint amennyire az oldalnak szüksége van:

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

GraphQL-lel egyetlen kérés van, általában POST egyetlen végpontra, például /graphql, amely lekérdezést visz:

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

A válasz pontosan tükrözi a lekérdezést:

{
  "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 }
      ]
    }
  }
}

Mindkettő JSON formátumot ad vissza. A különbség abban van, ki dönti el a szerkezetet: REST-nél a szerver, GraphQL-nél a hívó, a szerver sémája által megengedett keretek között.

Egymás melletti összehasonlítás

Hol melyik illik

Válaszd a RESTet, ha:

• tipikus appot építesz: foglalási rendszert, CRM-et, irányítópultot, webshopot.
• egy frontend egy backenddel beszél, és mindkettőt te irányítod.
• a lehető legegyszerűbben szeretnél hibakeresni, gyorsítótárazni és biztosítani.
• más szolgáltatások hívják majd az appodat (a webhookok és a legtöbb integráció REST-stílusú végpontokat vár).

Fontold meg a GraphQL-t, ha:

• több különböző kliens — weboldal, mobilapp, partneri integrációk — nagyon eltérő szeleteket igényel ugyanabból az adatból.
• az adataid mélyen összekapcsoltak (termékek, variánsok, értékelések, eladók, készlet), és a képernyőknek sokféleképpen kell kombinálniuk őket.
• olyan szolgáltatást használsz, amely a GraphQL-t kínálja fő API-jaként.

Hasznos szabály: ha nem vagy biztos benne, hogy szükséged van GraphQL-re, valószínűleg még nincs. Később könnyebb hozzáadni, mint eltávolítani.

Kulcsfogalmak

Gyakori tévhitek

• „A GraphQL újabb, tehát jobb.” Konkrét problémákat old meg. Egy egyetlen frontendes appnál gyakran plusz munkát ad, kevés haszonnal.
• „A GraphQL egy adatbázis.” Nem az. API-réteg; mögötte a szerver továbbra is az adatbázisodból olvas.
• „A GraphQL mindig gyorsabb.” Kevesebb kérés segíthet lassú mobilhálózaton, de egy korlátlan lekérdezés hatalmas mennyiségű adatot tölthet be. A teljesítmény a backendtől függ.
• „A REST szigorú szabványt jelent.” A gyakorlatban a „REST API” lazán azt jelenti: erőforrás-URL-ek, HTTP-metódusok és JSON. Sok jó API hajlítja a formális szabályokat.
• „A 200-as státusz azt jelenti, hogy működött.” GraphQL-nél ellenőrizd az errors mezőt — egy kérés részben meghiúsulhat, és mégis 200-zal térhet vissza.

Mit kérdezz az AI-építődtől

• „Használj egyszerű REST API-t JSON-nel, hacsak nincs egyértelmű ok az ellenkezőre — magyarázd el, ha szerinted GraphQL kell.”
• „Sorold fel minden végpontot, mit ad vissza, és ki hívhatja.”
• „Az ügyfél-oldalhoz csak azokat a mezőket add vissza, amelyeket az oldal használ.”
• „Adj lapozást a listavégpontokhoz, hogy soha ne adjanak vissza egyszerre több ezer sort.”
• „Ez a szolgáltatás csak GraphQL API-t kínál — szerverről hívd, a kulcsot tartsd titokban, és csak a szükséges mezőket kérd le.”
• „Adj megfelelő HTTP-státuszkódokat és JSON-hibaüzeneteket.”

REST és GraphQL a Mythexben

A Mythex dokumentációja tartalmaz egy receptet a REST API backend építéséhez kezdő prompttal, a backend pedig futhat Node-ban, Pythonban (FastAPI), C#-ban vagy Javában a webappod mellett. A dokumentáció nem ír le GraphQL-sablont, ezért ha szeretnél egyet, kérd kifejezetten, és indokold meg. Harmadik féltől származó GraphQL API hívása ugyanúgy működik, mint bármely más külső szolgáltatásé — lásd: integrálj bármilyen API-t. Kapcsolódó olvasmány: frontend vs backend és hogyan építs REST API-t.

Kérdések