REST vs GraphQL: u čemu je razlika i koji koristiti?

REST i GraphQL su dva načina dizajniranja API-ja, odnosno dogovorenog načina na koji ekrani vaše aplikacije (ili drugi programi) traže podatke od vašeg backenda. Kod REST-a postoji zaseban URL za svaku vrstu stvari, poput /customers ili /orders, i svaki vraća utvrđen oblik podataka. Kod GraphQL-a obično postoji jedan URL, a pozivalac šalje upit koji navodi tačno koja polja želi nazad. Za većinu aplikacija pravljenih uz AI, REST je jednostavniji i bolji podrazumijevani izbor.

Zašto je ovo važno kada gradite uz AI

Kada od AI alata za izgradnju zatražite "aplikaciju s backendom", on mora odlučiti kako će frontend i backend razgovarati. Ne morate to odlučivati svaki put, ali ćete vidjeti te pojmove u kodu, dokumentaciji i prilikom povezivanja s vanjskim servisima. Neki servisi nude samo jedan stil: mnogi servisi izlažu REST API-je, dok drugi, na primjer Shopify i GitHub, nude ili preferiraju i GraphQL. Poznavanje razlike pomaže vam da razumijete šta gledate i izbjegnete dodavanje složenosti koja vam nije potrebna. Ako vam je "API" novo, počnite s šta je API.

Svakodnevna analogija

REST je fiksni meni u restoranu. Svako jelo (endpoint) dolazi onako kako ga je kuhinja osmislila. Naručite jelo "customer" i dobijete cijeli tanjir — ime, email, adresu, datum registracije — čak i ako ste htjeli samo ime. Želite i nedavne narudžbine tog kupca? To je drugo jelo.

GraphQL je naručivanje po izboru od jednog konobara. Zapišete tačno šta želite: "ime kupca i datume i iznose njegove posljednje tri narudžbine". Jedna narudžba, jedan tanjir, samo ono što ste tražili. Ali kuhinja mora biti postavljena da obradi bilo koju kombinaciju koju kupci mogu zapisati.

Isti zahtjev na oba načina

Recimo da stranica kupca treba ime kupca i njegove tri najnovije narudžbine.

S REST-om, to su obično dva zahtjeva:

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

Prvi odgovor može sadržati više nego što stranica treba:

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

S GraphQL-om, to je jedan zahtjev, obično POST na jedan endpoint poput /graphql, koji nosi upit:

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

A odgovor tačno odražava upit:

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

Oba vraćaju JSON. Razlika je u tome ko odlučuje o obliku: kod REST-a to radi server; kod GraphQL-a to radi pozivalac, u okviru onoga što šema servera dozvoljava.

Uporedni pregled

Gdje koji odgovara

Odaberite REST kada:

• Gradite tipičnu aplikaciju: sistem za rezervacije, CRM, dashboard, prodavnicu.
• Jedan frontend razgovara s jednim backendom, a vi kontrolišete oba.
• Želite najjednostavniju stvar za debagovanje, keširanje i osiguravanje.
• Druge usluge će pozivati vašu aplikaciju (webhookovi i većina integracija očekuju endpointe u REST stilu).

Razmislite o GraphQL-u kada:

• Nekoliko različitih klijenata — web stranica, mobilna aplikacija, partnerske integracije — treba veoma različite dijelove istih podataka.
• Vaši podaci su duboko povezani (proizvodi, varijante, recenzije, prodavci, zalihe), a ekrani ih moraju kombinovati na mnogo načina.
• Koristite uslugu koja nudi GraphQL kao glavni API.

Korisno pravilo: ako niste sigurni da vam treba GraphQL, vjerovatno ne treba. Lakše ga je dodati kasnije nego ukloniti.

Ključni pojmovi

Uobičajene zablude

• "GraphQL je noviji, pa je bolji." Rješava određene probleme. Za jednu aplikaciju s jednim frontendom često dodaje posao bez velike koristi.
• "GraphQL je baza podataka." Nije. To je API sloj; iza njega server i dalje čita iz vaše baze.
• "GraphQL je uvijek brži." Manje zahtjeva može pomoći na sporim mobilnim mrežama, ali neograničen upit može učitati ogromne količine podataka. Performanse zavise od backenda.
• "REST znači strog standard." U praksi "REST API" znači labavo URL-ove resursa plus HTTP metode i JSON. Mnogi dobri API-ji savijaju formalna pravila.
• "Status 200 znači da je uspjelo." Kod GraphQL-a provjerite polje errors — zahtjev može djelimično propasti i ipak vratiti 200.

Šta tražiti od AI alata za izgradnju

• "Koristi jednostavan REST API s JSON-om osim ako postoji jasan razlog da ne — objasni ako misliš da treba GraphQL."
• "Navedi svaki endpoint, šta vraća i ko smije da ga poziva."
• "Za stranicu kupca vrati samo polja koja stranica koristi."
• "Dodaj paginaciju na endpointe s listama da nikada ne vraćaju hiljade redova odjednom."
• "Ovaj servis ima samo GraphQL API — pozovi ga sa servera, čuvaj ključ u tajni i traži samo polja koja su nam potrebna."
• "Vraćaj ispravne HTTP statusne kodove i JSON poruke o greškama."

REST i GraphQL u Mythexu

Mythex-ova dokumentacija uključuje recept za izgradnju REST API backenda sa početnim upitom, a backend može raditi u Node, Python (FastAPI), C# ili Java uz vašu web aplikaciju. Dokumentacija ne opisuje GraphQL šablon, pa ako ga želite, zatražite ga izričito i recite zašto. Pozivanje GraphQL API-ja treće strane radi kao i svaka druga vanjska usluga — pogledajte integriši bilo koji API. Povezano štivo: frontend vs backend i kako napraviti REST API.

Pitanja