REST vs GraphQL: koks skirtumas ir kurį naudoti?

REST ir GraphQL – du būdai projektuoti API: sutartas būdas, kuriuo jūsų programėlės ekranai (ar kitos programos) prašo duomenų iš serverio. Su REST kiekvienam daiktui yra atskiras URL adresas, pvz., /customers ar /orders, ir kiekvienas grąžina nustatytos formos duomenis. Su GraphQL dažniausiai yra vienas URL adresas, o kreipiantysis siunčia užklausą, kurioje išvardija tiksliai, kokių laukų nori. Daugumai programėlių, kurias kuriate su DI, REST yra paprastesnis ir geresnis numatytasis pasirinkimas.

Kodėl tai svarbu kuriant su DI

Kai DI įrankiui prašote „programėlės su serveriu“, jis turi nuspręsti, kaip frontend ir backend bendrauja. Kiekvieną kartą to nereikia spręsti pačiam, bet kode, dokumentacijoje ir jungiantis prie išorinių paslaugų šiuos terminus pamatysite. Kai kurios paslaugos siūlo tik vieną stilių: daugybė paslaugų atskleidžia REST API, o kitos – kaip Shopify ir GitHub – taip pat siūlo ar teikia pirmenybę GraphQL. Skirtumo žinojimas padeda suprasti, ką matote, ir nepridėti nereikalingo sudėtingumo. Jei „API“ jums naujas terminas, pradėkite nuo kas yra API.

Kasdienė analogija

REST – tai fiksuotas meniu restorane. Kiekvienas patiekalas (galinis taškas) atkeliauja taip, kaip jį sukūrė virtuvė. Užsakote patiekalą „klientas“ ir gaunate visą lėkštę – vardą, el. paštą, adresą, registracijos datą – net jei norėjote tik vardo. Norite ir paskutinių kliento užsakymų? Tai antras patiekalas.

GraphQL – tai užsakymas pagal pasirinkimą iš vieno padavėjo. Užrašote tiksliai, ko norite: „kliento vardą ir paskutinių trijų užsakymų datas bei sumas“. Vienas užsakymas, viena lėkštė, tik tai, ko prašėte. Bet virtuvė turi būti pasiruošusi bet kokiam deriniui, kurį klientai gali užrašyti.

Ta pati užklausa dviem būdais

Tarkime, kliento puslapiui reikia kliento vardo ir trijų naujausių jo užsakymų.

Su REST paprastai reikia dviejų užklausų:

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

Pirmas atsakymas gali turėti daugiau nei puslapiui reikia:

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

Su GraphQL tai viena užklausa, paprastai POST į vieną galinį tašką, pvz., /graphql, su užklausa:

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

Ir atsakymas tiksliai atitinka užklausą:

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

Abu atsakymai grąžina JSON. Skirtumas – kas nustato formą: REST atveju serveris, GraphQL atveju kreipiantysis, bet tik tiek, kiek leidžia serverio schema.

Lyginimas šalia šalies

Kur tinka kiekvienas

Rinkitės REST, kai:

• kuriate įprastą programėlę: rezervacijų sistemą, CRM, valdymo skydelį, parduotuvę;
• vienas frontend bendrauja su vienu backend, o abu valdote patys;
• norite paprasčiausio dalyko derinti, talpinti podėlyje ir apsaugoti;
• kitos paslaugos kreipsis į jūsų programėlę (webhook'ai ir dauguma integracijų tikisi REST stiliaus galinių taškų).

Apsvarstykite GraphQL, kai:

• keli skirtingi klientai – svetainė, mobilioji programėlė, partnerių integracijos – reikalauja labai skirtingų tų pačių duomenų dalių;
• jūsų duomenys stipriai susieti (produktai, variantai, atsiliepimai, pardavėjai, atsargos) ir ekranams reikia juos derinti įvairiais būdais;
• naudojate paslaugą, kurios pagrindinis API yra GraphQL.

Naudinga taisyklė: jei nesate tikri, ar jums reikia GraphQL, greičiausiai dar nereikia. Ją lengviau pridėti vėliau, nei pašalinti.

Pagrindiniai terminai

Dažnos klaidingos nuomonės

• „GraphQL naujesnė, todėl geresnė.“ Ji sprendžia konkrečias problemas. Vienai programėlei su vienu frontend ji dažnai prideda darbo be didelės naudos.
• „GraphQL – tai duomenų bazė.“ Nėra. Tai API sluoksnis; už jo serveris vis tiek skaito iš jūsų duomenų bazės.
• „GraphQL visada greitesnė.“ Mažiau užklausų gali padėti lėtuose mobiliuosiuose tinkluose, bet neribota užklausa gali įkelti milžiniškus duomenų kiekius. Našumas priklauso nuo backend.
• „REST reiškia griežtą standartą.“ Praktikoje „REST API“ laisvai reiškia išteklių URL adresus, HTTP metodus ir JSON. Daugelis geros kokybės API formalias taisykles šiek tiek lenkia.
• „Būsena 200 reiškia, kad pavyko.“ GraphQL atveju tikrinkite errors lauką – užklausa gali iš dalies nepavykti ir vis tiek grąžinti 200.

Ką paklausti savo DI įrankio

• „Naudok paprastą REST API su JSON, nebent yra aiški priežastis to nedaryti – paaiškink, jei manai, kad reikia GraphQL.“
• „Išvardyk kiekvieną galinį tašką, ką jis grąžina ir kas gali jį kviesti.“
• „Kliento puslapiui grąžink tik tuos laukus, kuriuos puslapis naudoja.“
• „Pridėk puslapiavimą sąrašų galiniams taškams, kad jie niekada negrąžintų tūkstančių eilučių iškart.“
• „Šiai paslaugai yra tik GraphQL API – kviesk ją iš serverio, raktą laikyk paslaptyje ir prašyk tik reikalingų laukų.“
• „Grąžink tinkamus HTTP būsenos kodus ir JSON klaidų pranešimus.“

REST ir GraphQL Mythex

Mythex dokumentacijoje yra receptas REST API backend kūrimui su pradine užklausa, o backend gali veikti Node, Python (FastAPI), C# ar Java kartu su jūsų žiniatinklio programėle. Dokumentacijoje nėra GraphQL šablono, todėl jei jo norite, aiškiai paprašykite ir paaiškinkite kodėl. Trečiosios šalies GraphQL API kvietimas veikia kaip bet kuri kita išorinė paslauga – žr. integruoti bet kokį API. Susijusi medžiaga: frontend ir backend ir kaip sukurti REST API.

Klausimai