REST API

A REST API, vagy teljesebb nevén RESTful API technológia mondhatni de-facto ipari szabvánnyá nőtte ki magát. Minden weboldal, ami rendelkezik igénybevehető API-val RESTful módon kommunikál. Ennek az oka az, hogy a REST a már ismert HTTP technológiát használja átvitelre és az adatok általában JSON formátumban érkeznek, amit szinte minden nyelvből használni tudunk, de alapvetően a JSON-ra a választás webes kliensek miatt esett.

A REST nem új keletű dolog, 2000-ben definiálta a kifejezést Roy Fielding a szakdolgozatában és a REST egy mozaikszó, ami a Representational State Transfer szavak rövidítése. Azokat a rendszereket, amelyek eleget tesznek a REST megkötésének, RESTful-nak nevezzük.

A REST megkötései:

• Egységes interfész (Uniform interface)

  Az egységes kliens-szerver interfész alapvető a RESTful rendszerek tervezéséhez. Egyszerűsíti és elválasztja az architektúrát. Ezáltal lehetővé teszi, hogy egymástól függetlenül fejlődjenek az egyes részek. Az interfész négy irányadó elve alább kerül részletezésre.

• Kliens-szerver architektúra (Client-server decoupling)

  A kliensek el vannak különítve a szerverektől egy egységes interfész által. Az érdekeltségek ilyen nemű szétválasztása azt jelenti például, hogy a kliensek nem foglalkoznak adattárolással, ami a szerver belső ügye marad, és így a kliens kód hordozhatósága megnő. A szerverek nem foglalkoznak a felhasználói felülettel vagy a kliens állapotával, így a szerverek egyszerűbbek és még skálázhatóbbak lehetnek. A szerverek és kliensek áthelyezhetőek és fejleszthetőek külön-külön is, egészen addig, amíg az interfész nem változik meg.

• Állapotmentesség (Statelessness)

  Az állapotmentesség egy olyan kommunikációs protokoll, amiben a kérést fogadó szerver nem tárol el adatot a kliensről. A kliens-szerver kommunikáció állapotmentes az által, hogy minden egyes kérés bármelyik klienstől tartalmazza az összes szükséges információt a kérés kiszolgálásához, és minden állapotot a kliens tárol. A szerver lehet állapottartó; ez a korlátozás csupán azt követeli meg, hogy a szerver oldali erőforrás-állapotok URL által címezhetőek legyenek. Ez nem csak a szerver felügyeletét teszi lehetővé, de megbízhatóbbá teszi őket a hálózati meghibásodásokkal szemben, valamint tovább fokozza a skálázhatóságot.

• Gyorsítótárazhatóság (Cacheability)

  Mint ahogy a világhálón, a kliensek és a közvetítők képesek gyorsítótárazni a válaszokat. A válaszoknak ezért közvetlenül vagy közvetve tartalmazniuk kell, hogy gyorsítótárazhatóak-e vagy sem. Így elkerülhető, hogy a kliens téves vagy elavult adatokat használjon fel újra. Egy jól implementált gyorsítótár lehetővé teszi, hogy teljesen megkerüljünk egyes kliens-szerver interakciókat, ezzel megnövelve a rendszer skálázhatóságát és a teljesítményét.

• Réteges felépítés (Layered system architecture)

  Egy kliens általában nem tudja megmondani, hogy közvetlen csatlakozott-e a végpont szerverhez, vagy közvetítő segítségével. A közvetítő szerverek megnövelhetik a rendszer skálázhatóságát terheléseloszlással és megosztott gyorsítótárak használatával.

• Igényelt kód (opcionális) (Code on demand)

  A szerverek képesek időlegesen kiterjeszteni vagy testre szabni egy kliens funkcionalitását programrészek átadásával, amelyeket a kliens futtatni képes. Ide tartoznak az előre fordított komponensek (pl. bináris futtatható állományok) és a kliens oldali szkriptek (pl. JavaScript).

Az egységes interfészre további megkötések is vonatkoznak. Ezek:

• Resource-Based

  Az erőforrások, mint például adatobjektumok vagy szolgáltatások URI-k (Uniform Resource Identifier) által vannak azonosítva. Ezeket az erőforrásokat standard HTTP módszerekkel lehet manipulálni.

• HTTP módszerek

  A REST standard HTTP módszereket (GET, POST, PUT, DELETE, stb.) használ az erőforrások műveleteinek végrehajtására. Minden módszernek konkrét jelentése kell legyen, és amennyire csak lehet, idempotensnek¹ kell lennie.

• Reprezentáció

Az erőforrásoknak többféle reprezentációjuk lehet, például JSON, XML, HTML vagy mások. A kliensek kérhetnek egy specifikus reprezentációt az igényeiknek megfelelően.

A rugalmasság nagy előnye a REST-nek, de ugyanez a rugalmasság könnyen visszaüthet. Nagyon könnyen lehet gyenge vagy hibásan működő API-t tervezni. Illetve még nagy probléma a flexibilitás miatt a szerver és kliens közötti kölcsönös megértés.

Éppen ezért létrehozták az OpenAPI specifikációt, hogy a REST-en egymással kommunikáló eszközök könnyen megértsék egymást. Az OpenAPI specifikáció alapján kód is generálható. A teljes specifikáció a https://swagger.io/specification/ címen található.