Kad se bira protokol za komunikaciju između servisa, lako je posegnuti za onim koji je najpoznatiji umjesto onim koji najbolje odgovara problemu. REST, gRPC i WebSockets rješavaju bitno različite scenarije komunikacije, pa vrijedi razumjeti razlike prije nego što arhitektura naraste i promjena postane skupa.
REST — jednostavan, sinkroni request/response
REST je "leća default" izbor iz dobrog razloga: temelji se na HTTP-u, čitljiv je čovjeku (JSON), lako se debugira alatima poput curl-a ili Postmana i ima ogroman ekosustav. Idealan je za javne API-je i komunikaciju klijent-server gdje se svaki zahtjev tretira neovisno. Mana je veći overhead po pozivu (JSON parsing, tekstualni protokol) i nedostatak nativnog streaminga.
gRPC — brzina i strogi kontrakti
gRPC koristi Protocol Buffers (binarni format) preko HTTP/2, što donosi znatno manju latenciju i manju veličinu poruka u odnosu na JSON preko HTTP/1.1. Kontrakt između servisa definira se u .proto datoteci, iz koje se generira kod za klijenta i server u desetak jezika — nema ručnog pisanja DTO-ova ni nesuglasica oko naziva polja. gRPC nativno podržava streaming (jednosmjerni i dvosmjerni), što ga čini prirodnim izborom za komunikaciju servis-servis unutar mikroservisne arhitekture.
Cijena te brzine je čitljivost — poruke su binarne pa se ne mogu pregledati golim okom bez alata, a debug proces zahtijeva malo više opreme (grpcurl, BloomRPC i slično). gRPC također slabije radi izravno iz preglednika bez posredničkog proxyja (gRPC-Web).
WebSockets — pravi real-time, dvosmjerno
REST i gRPC su prvenstveno request/response modeli — klijent traži, server odgovara. WebSockets otvara jednu trajnu, dvosmjernu vezu preko koje obje strane mogu slati poruke bilo kada, bez ponovnog uspostavljanja konekcije. To ga čini pravim izborom za chat aplikacije, live notifikacije, kolaborativne alate (Google Docs stil), burzovne tickere ili multiplayer igre — sve gdje server treba proaktivno gurnuti podatak klijentu čim se nešto promijeni.
Nedostaci: veza je stateful, što otežava horizontalno skaliranje (treba sticky sessions ili poseban message broker poput Redisa za sinkronizaciju između instanci), a infrastruktura (load balanceri, firewall pravila) ponekad zahtijeva dodatnu konfiguraciju u odnosu na običan HTTP.
Brza usporedba
| REST | gRPC | WebSockets | |
|---|---|---|---|
| Format | JSON (tekst) | Protobuf (binarno) | Bilo koji (obično JSON) |
| Model | Request/response | Request/response + streaming | Dvosmjerno, trajno |
| Čitljivost | Visoka | Niska bez alata | Ovisi o formatu poruke |
| Tipičan slučaj | Javni API | Servis-servis, interno | Real-time UI |
Kako birati
Za javni API koji koriste vanjski developeri — REST, zbog jednostavnosti i čitljivosti. Za internu komunikaciju između mikroservisa gdje su latencija i propusnost bitni — gRPC. Za bilo što gdje server mora proaktivno obavijestiti klijenta o promjeni bez pollinga — WebSockets. Ništa ne sprječava kombinaciju sve tri unutar iste arhitekture: gRPC između internih servisa, REST prema vanjskim klijentima, WebSockets za konkretan real-time dio proizvoda.
Zaključak
Ne postoji jedan "najbolji" protokol — postoji najbolji protokol za konkretan par (tko govori s kim, koliko često, koliko brzo treba stići poruka). Razumijevanje tih razlika prije pisanja prve linije koda štedi mjesece kasnijeg refaktoriranja.
