REST ili GraphQL?

Pitanje "REST ili GraphQL" postavlja se na gotovo svakom kickoff sastanku novog backend projekta. Odgovor nije univerzalan — oba pristupa rješavaju isti problem (kako klijent dohvaća podatke sa servera), ali na temeljno različite načine, sa svojim kompromisima.

Kako radi REST

REST (Representational State Transfer) organizira API oko resursa i standardnih HTTP metoda: GET /users/42, POST /orders, DELETE /comments/7. Svaki endpoint vraća unaprijed definiranu strukturu podataka. Jednostavan je za razumjeti, dobro se keširа na razini HTTP-a (CDN-ovi, browser cache) i ima desetljećima izgrađen ekosustav alata.

Kako radi GraphQL

GraphQL okreće model naglavačke — postoji jedan endpoint, a klijent u upitu sam specificira točno koja polja želi:

query {
  user(id: 42) {
    name
    orders(last: 5) {
      total
    }
  }
}

Server vraća točno traženu strukturu, ništa više. Ovo eliminira dva klasična REST problema: over-fetching (dohvaćanje podataka koji se ne koriste) i under-fetching (potreba za više uzastopnih poziva da se sastavi jedan ekran).

Prednosti REST-a

• Jednostavnost — svatko tko je ikad koristio HTTP razumije REST za pet minuta.
• Keširanje "iz kutije" preko standardnih HTTP mehanizama.
• Zreo ekosustav — API gateway-i, monitoring alati, dokumentacija (OpenAPI/Swagger).
• Jasne granice resursa olakšavaju rate limiting i autorizaciju po endpointu.

Prednosti GraphQL-a

• Klijent dobiva točno ono što traži, što je posebno korisno za mobilne aplikacije s ograničenim podatkovnim prometom.
• Jedan upit umjesto lančanih poziva prema više REST endpointa.
• Strogo tipizirana shema koja služi kao živa dokumentacija i omogućuje alate poput GraphQL Playgrounda.
• Lakša evolucija API-ja — nova polja se mogu dodavati bez verzioniranja endpointa.

Mane koje se rijetko spominju

GraphQL uvodi vlastite izazove: keširanje na HTTP razini gotovo ne postoji jer je sve na jednom endpointu, N+1 upiti prema bazi lako se prošuljaju bez alata poput DataLoadera, a pisanje resolvera i upravljanje kompleksnošću upita (uključujući zaštitu od predubokih ili preskupih upita) zahtijeva dodatnu disciplinu. REST, s druge strane, zna dovesti do "API zoo" problema — desetke specijaliziranih endpointa za svaki mogući prikaz podataka.

Kada koristiti koji

REST je i dalje dobar izbor za: javne API-je gdje je jednostavnost i keširanje prioritet, mikroservise s jasno definiranim, stabilnim resursima, te timove bez prethodnog iskustva s GraphQL ekosustavom.

GraphQL opravdava svoju složenost kad: frontend ima mnogo različitih prikaza istih podataka (web, mobitel, widgeti), postoji potreba za agregacijom podataka iz više izvora iza jednog upita, ili tim aktivno razvija i frontend i backend pa korist od tipizirane sheme dolazi do izražaja.

Zaključak

Nema pobjednika u apsolutnom smislu — postoji samo bolji izbor za konkretan projekt. Mnoge veće kompanije danas kombiniraju oba pristupa: REST za jednostavne, stabilne resurse i javne integracije, GraphQL kao agregacijski sloj iznad njih za zahtjevnije frontend scenarije.