Při práci s API se často setkáte s REST a gRPC. I když Rest dominuje této oblasti již mnoho let, gRPC se ukazuje jako důstojný konkurent.
Rest a gPRC jsou dva různé způsoby, jak můžete navrhnout API. Rozhraní API fungují jako komunikační most mezi službami, které mohou představovat složité systémy umístěné v různých počítačích nebo napsané v různých jazycích.
Tento článek představí Rest i gRPC, podělí se o jejich podobnosti, rozdíly a kde je použít.
Table of Contents
Co je to odpočinek?
Odpočinek (Representational State Transfer) je architektonický softwarový přístup, který diktuje pravidla, jak si softwarové komponenty vyměňují data. Rest je založen na standardním komunikačním protokolu webu HTTP.
Všechna rozhraní API založená na architektonickém stylu REST se nazývají RESTful API. Na druhou stranu webové služby navazující na architektonický design REST jsou známé jako webové služby RESTful.
Architektonický styl REST se řídí těmito principy;
- Jednotné rozhraní: Server by měl přenášet data ve standardním formátu. Přenášená data však mohou být v jiném formátu, než je interní reprezentace prostředku serverové aplikace.
- Bezstavovost: Server by měl dokončit každý požadavek klienta nezávisle, bez ohledu na předchozí požadavky. Požadavky klientů na zdroje mohou být v libovolném pořadí a každý požadavek je izolován od ostatních.
- Vrstvený systém: Představuje vrstvu autorizovaných prostředníků mezi serverem a klientem. Klient se může spojit s těmito autorizovanými zprostředkovateli a stále přijímat odpovědi ze serveru.
- Možnost ukládání do mezipaměti: Některé odpovědi jsou uloženy u zprostředkovatele nebo klienta, aby se zlepšila doba odezvy.
- Kód na vyžádání: Servery dočasně přizpůsobí nebo rozšíří funkčnost klienta přenosem softwarového programovacího kódu na klienta.
Výhody REST
- Škálovatelnost: REST API jsou známá svou škálovatelností, protože optimalizují interakce klient-server. Mezipaměť a stav bez stavu jsou hlavní funkce, které snižují zatížení serveru.
- Flexibilní: RESTful API nabízí úplné oddělení klient-server. Tyto služby oddělí a zjednoduší různé serverové komponenty, které se mohou vyvíjet nezávisle.
- Nezávislost: Serverové a klientské aplikace můžete psát v různých programovacích jazycích, aniž byste ovlivnili návrh rozhraní API.
Případy použití Rest
- Webová rozhraní API
- webové služby
- Architektura mikroslužeb
Co je to gRPC?
gRPC je rámec vzdáleného volání procedur (RPC), který lze spustit v jakémkoli prostředí. Tento open-source framework je navržen jako vysoce výkonný protokol, který dokáže efektivně propojit služby napříč datovými středisky a v nich.
Klientská aplikace může volat metodu na serverové aplikaci na jiném počítači, jako by to byl lokální objekt. Pomocí gRPC definujete službu a určujete metody, které můžete vzdáleně volat, s jejich parametry a typy návratů.
gRPC má zásuvnou kontrolu stavu, autentizaci, vyvažování zátěže a podporu sledování. Tento framework používá pro přenos dat HTTP 2 a Protocol Buffers. Při výměně dat se místo adresy URL zdroje volá procedura
Výhody gRPC
- Škálovatelnost: gRPC vám umožňuje nainstalovat běhová prostředí jediným příkazem a začít škálovat miliony RPC za sekundu.
- Jednoduchá definice služby: Pomocí vyrovnávací paměti protokolů definujte své služby a zprovozněte je.
- Víceplatformní: Tento rámec generuje idiomatické klientské a serverové útržky pro různé platformy a jazyky.
- Obousměrné streamování a integrované ověřování.
Případy použití gRPC
- Webová rozhraní API
- webové služby
- Streamovací aplikace
- Komunikace mikroslužeb
Podobnosti mezi REST a gRPC
- Mechanismus výměny dat: Oba architektonické návrhy umožňují serverům a klientům vyměňovat si data. Tyto údaje jsou však sdíleny na základě určitých pravidel.
- Vhodné pro škálovatelné a distribuované systémy: Asynchronní komunikace a bezstavový design REST i gRPC usnadňují škálování jejich API.
- Používat komunikaci založenou na HTTP: Oba používají HTTP, nejpreferovanější komunikační protokol webu.
- Flexibilní: REST a gRPC můžete používat s různými programovacími jazyky a technologiemi.
REST vs. gRPC: Deep Dive Comparison
Služby REST a gRPC se liší následujícími způsoby;
Výměna dat
V REST API musí být data předaná z jedné softwarové komponenty do druhé vyjádřena ve formátu JSON. JSON musí být serializován a přeložen do programovacího jazyka pro výměnu dat. Rozhraní Rest API však mohou také vyměňovat datové formáty jako HTML a XML.
gRPC standardně používá formát Protocol Buffers. Nativně však podporuje i JSON. Protokolové vyrovnávací paměti nejsou čitelné pro člověka. Server používá jazyk popisu rozhraní Protocol Buffer k definování datové struktury. gPRC poté serializuje datovou strukturu do binárního formátu. Poté deserializuje data do libovolného specifikovaného programovacího jazyka.
Komunikační model
V REST klient odešle jeden požadavek na server; server poté odešle odpověď. Klient musí před pokračováním v operacích počkat na odpověď serveru. Je to model žádost-odpověď.
V gRPC může klient posílat jeden nebo více serverových požadavků, což má za následek jednu nebo více odpovědí. Datová připojení mohou být mnoho-k-mnoho, many-to-one, one-to-many nebo one-to-one. gRPC používá komunikační model klient-reakce.
Generování kódu
gRPC má vestavěné nativní funkce generování kódu na straně serveru a klienta. Tyto funkce můžete najít v různých jazycích díky kompilátoru Protocol Buffers. gRPC generuje kód na straně serveru a na straně klienta po definování struktury v souboru proto.
REST postrádá vestavěné funkce generování kódu. Pokud tuto funkci potřebujete, můžete použít nástroje třetích stran.
HTTP protokol
REST API používají HTTP 1.1. Chcete-li odeslat požadavek na službu REST, potřebujete adresu URL zdroje. HTTP 1 odesílá informace mezi počítačem a webovým serverem. Adresa URL zdroje ve službě REST je viditelná pro klienta. Návrháři API řídí strukturu adres URL zdrojů.
gRPC používá HTTP 2. Tato verze HTTP byla představena v roce 2015 a používá se v prohlížečích jako Internet Explorer, Safari a Chrome. Na rozdíl od HTTP 1, který uchovává vše v prostém textu, tento novější formát využívá zapouzdření binárního formátu, což má za následek více možností doručování dat a urychlení celého procesu.
Struktura dat užitečné zátěže
REST používá XML nebo JSON k odesílání a přijímání dat. JSON je nejpoužívanější formát pro odesílání dynamických dat v REST, protože je flexibilní a nevyžaduje žádnou strukturu. Data JSON jsou také čitelná pro člověka. Jediný problém s JSON není tak rychlý, protože musí být serializován a přeložen během přenosu dat.
gRPC používá protokolové vyrovnávací paměti k serializaci dat užitečného zatížení. Jedná se o vysoce komprimovaný formát, který snižuje data zpráv. Tento rámec používá Protobuf k automatickému převodu zpráv se silným typem do programovacích jazyků klienta a serveru.
Podpora prohlížeče
REST je podporován ve všech prohlížečích, protože používá HTTP 1.1. Díky tomu je ideální volbou pro webové služby a rozhraní API.
gRPC má omezenou podporu pro prohlížeče, protože je založen na HTTP 2. Chcete-li podporovat všechny prohlížeče, musíte přidat gRPC-web jako proxy vrstvu. Z tohoto důvodu se gRPC většinou používá pro interní systémy.
Propojení klient-server
REST je volně propojený architektonický návrh. Znamená to, že klient a server nemusí vědět o svých implementacích. Tato funkce usnadňuje vývoj RESTful API v průběhu času, protože nemusíte měnit klientský kód, když měníte definice serveru.
gRPC je pevně propojený rámec, kde server a klient musí mít přístup ke stejnému proto souboru. Pokud potřebujete v souboru provést nějaké změny, musíte také aktualizovat server a klienta.
Odpočinek vs. gRPC
FunkceRESTgRPCHTTP protokolHTTP 1.1HTTP 2Podpora prohlížečePodporuje všechny prohlížeče, protože používá HTTP 1.1 Menší podpora prohlížečů, protože používá HTTP 2Generování kóduPoužívá nástroje třetích stran Vestavěné funkce generování kóduNávrhový přístup Návrh orientovaný na entity Přístup orientovaný na službyPřístup k datům Běžné adresy URLSlužbyNevyžaduje se obousměrný streaming datU REST na straně klienta nebo serveru GRPC software je nutný jak na straně klienta, tak na straně serveru. Komunikační model Jeden klient komunikuje s jedním serveremVíce komunikačních modelů, jako je jeden klient odesílá požadavky na více serverů, jeden server komunikuje s více klienty nebo jeden server komunikuje s jedním klientem.
Kdy použít REST
RESTful API a webové služby jsou velmi oblíbené. Služby RESTful se snadno implementují, strukturují data, jsou flexibilní a čitelné. REST můžete použít v následujících případech;
- Webové architektury: Pomocí architektonického návrhu REST můžete vytvářet webová, mobilní a multiplatformní rozhraní API.
- Jednoduchá datová komunikace: REST používá JSON, snadno čitelný datový formát.
- Public-facing API: Pokud máte v úmyslu veřejnost využívat data a používat vaše API, REST bude dobrou volbou kvůli jeho funkci čitelnosti.
Kdy použít gRPC
gRPC není tak populární jako služby RESTful. Má však také jedinečné funkce, díky kterým vynikne v následujících aplikacích;
- Vícejazyčné systémy: gRPC vyhovuje architekturám mikroslužeb napsaných v různých programovacích jazycích, kde se rozhraní API pravděpodobně nezmění.
- Připojení mikroslužeb: Funkce jako obousměrné streamování a nízká podpora prohlížeče dělají z gRPC dobrou volbu pro interní rozhraní API.
- Sítě streamování v reálném čase: gRPC můžete používat s interními službami, které se zabývají velkým zatížením dat a vyžadují streamování v reálném čase.
Názor autorů
I když má gRPC některé specifické funkce, které mohou zastínit REST v aplikacích, jako je Internet věcí, ten druhý vítězí díky své čitelnosti, flexibilitě a širokému přijetí. Nižší podpora prohlížeče gRPC z něj dělá nepříliš dobrou volbu pro vývojáře, kteří chtějí vytvářet webové služby.
Univerzální podpora pro služby RESTful činí z REST ideální architektonický styl API pro integraci webu a mikroslužeb.
Závěr
REST a gRPC patří mezi mnoho architektonických stylů API, které si můžete vybrat při sestavování svého dalšího API. Konečný výběr bude záviset na produktu, který chcete postavit. Služby RESTful se budou perfektně hodit při vytváření veřejných rozhraní API, zatímco gRPC je dobrou volbou pro služby, jako jsou mobilní aplikace, které nevyžadují podporu prohlížeče.
Dále se podívejte na náš článek o tom, jak vytvořit gRPC od nuly pomocí Java.