REST, RPC, GraphQL és egyedi API: hogyan érdemes választani?

Célok

A lecke végére össze tudod hasonlítani a REST-szemléletű HTTP API-t, az RPC/gRPC-t, a GraphQL-t és az egyedi API-t, és meg tudod indokolni, melyik mikor illik.

Miért kell?

Egy rendszerben több stílus is együtt élhet: publikus HTTP API, belső gRPC, GraphQL-alapú kliensaggregáció. A választás a fogyasztótól, a művelettől és a változási igénytől függ, nem a stílus rangsorától.

Azonos probléma, eltérő interfész

Egy művelet (például egy erőforrás létrehozása) kifejezhető: REST-szemléletű POST /elemek, majd GET /elemek/42; RPC-ben CreateItem és GetItem; GraphQL-ben mutation; egyedi protokollban item.create típusú üzenet. Mindegyiknél ugyanaz az üzleti szabály, jogosultság és ismétlésvédelem szükséges (6.5). A különbség az interfész kifejezőeszközeiben, a toolingban és a fogyasztói kapcsolatban van.

Szempont	REST-szemléletű HTTP	RPC / gRPC	GraphQL	Egyedi API
Központi fogalom	Erőforrás, reprezentáció	Művelet, típusos üzenet	Séma, mezőigény	Saját szerződés
Erősség	HTTP-ökoszisztéma, közvetítők, gyorsítótár	Belső hívások, generálás, streaming	Eltérő kliensigények	Speciális követelmény
Kliens eszközei	HTTP-kliens, leíró nyelv	Generált stub	Lekérdezés, sémaismeret	Saját kliens
Összetett olvasás	Több végpont vagy aggregáció	Összefoglaló művelet	Mezőalapú lekérdezés	Saját művelet
Fő kockázat	Chatty API	Túl finom távoli metódusok	Lekérdezési költség, N+1	Hiányos saját szabályok
Gyorsítótár	HTTP-eszközökkel közvetlen	Alkalmazásszinten	Query- és adatmodellfüggő	Saját szabályok

A táblázat nem minőségi rangsor. Az erősség csak akkor előny, ha a használati helyzet igényli.

Egyedi API

Egyedi API az, amely saját műveleteket és üzenetszabályokat definiál, akár HTTP, akár más szállítás fölött. Nem szükséges REST-nek nevezni ahhoz, hogy jó legyen: használhat szabványos HTTP-metódust és státuszt, miközben a tartalom jelentése saját szerződés. Indokolt lehet speciális üzleti műveletnél, örökölt rendszernél vagy egyszerű integrációnál. A korlát az, hogy a közös eszközök kevesebbet tudnak az alkalmazási jelentésről, ezért a szerződést géppel feldolgozhatóan kell leírni.

Fogyasztó és bizalmi határ

Publikus API-nál a széles eszköztámogatás, a dokumentáció és a lassú kliensfrissítések számítanak. Belső szolgáltatásoknál a típusos szerződés és a közös eszközök könnyebben vállalhatók. Böngészőnél az elérhető szállítások és a hitelesítés korlátoz.

• GraphQL: ha több kliens ugyanazon gráf különböző részhalmazait használja.
• RPC: ha a határ üzleti műveleteket publikál.
• REST-szemléletű HTTP: ha stabil erőforrás-életciklus van, és a HTTP-funkciók (gyorsítótár, feltételes kérés) segítenek.
• Egyedi API: ha egyik sem illik, a szabadságért több szabály és eszköz fenntartásának árán.

Együttélés és adapterek

A külső interfész nem szükségképpen azonos a belsővel. Egy BFF (backend for frontend, részletesen a 7.6 leckében) GraphQL-lekérdezést fogadhat, miközben gRPC-n és HTTP-n kér adatot a szolgáltatásoktól. Az adapternek a hibákat, időkereteket és jogosultsági kontextust is fordítania kell; nem tüntethet el minden belső hibát sikeres üres válaszként. A túl sok stílus növeli a tanulási és működtetési költséget, ezért a változatosság okát dokumentálni kell, és közös irányelvek segítenek.

Gyakori tévhitek

Állítás	Pontosítás
„A GraphQL a REST utódja.”	Eltérő kompromisszumok, együtt is élhetnek.
„A gRPC mindig gyorsabb.”	Belső hívásnál előnyös lehet, böngészőből nem közvetlen.
„A stílus neve biztosítja a helyes állapotváltozást.”	Az üzleti szabály, jogosultság és ismétlésvédelem stílusfüggetlen.
„Minden szolgáltatás használhat mást.”	A sokféleség költség; közös irányelvek kellenek.

Röviden

• A választás a fogyasztótól, a műveletektől és a változási igénytől függ.
• A REST HTTP-eszközöket, az RPC típusos belső hívást, a GraphQL mezőigényt, az egyedi API speciális szerződést ad.
• Egy rendszerben több stílus élhet, adapterekkel.
• Az üzleti szabály stílusfüggetlen.

Ellenőrző kérdések

1. Melyik stílust választanád sokféle klienst kiszolgáló API-hoz, és melyiket belső készletfoglaláshoz?
2. Mi a kockázata a túl sokféle API-stílusnak?
3. Mikor indokolt egyedi API?

Források

• Roy Fielding: REST architekturális stílus
• gRPC core concepts
• GraphQL: Performance