Често се сусрећемо са појмовима REST и gRPC приликом рада са API-јима. Иако REST доминира овом облашћу већ дуги низ година, gRPC се показује као вредан такмац.
REST и gRPC су два различита приступа дизајнирању API-ја. API-ји делују као комуникациони мост између услуга, које могу представљати сложене системе смештене на различитим рачунарима или написане на различитим програмским језицима.
Овај чланак ће представити оба, REST и gRPC, упоредити њихове сличности, разлике и препоручити када који користити.
Шта је REST?
REST (Representational State Transfer) представља архитектонски приступ у развоју софтвера који дефинише правила за размену података између софтверских компоненти. REST се ослања на стандардни комуникациони протокол веба, HTTP.
Сви API-ји који су засновани на REST архитектонском стилу називају се RESTful API-ји. С друге стране, веб сервиси који следе REST архитектонски дизајн познати су као RESTful веб сервиси.
REST архитектонски стил се руководи следећим принципима:
- Јединствен интерфејс: Сервер мора преносити податке у стандардном формату. Међутим, пренесени подаци могу бити у различитом формату од интерног приказа ресурса у серверској апликацији.
- Без стања: Сервер треба да обради сваки захтев клијента независно, без освртања на претходне захтеве. Захтеви клијената за ресурсима могу стизати било којим редоследом, а сваки захтев је изолован од осталих.
- Слојевити систем: Постоји слој овлашћених посредника између сервера и клијента. Клијент се може повезати са тим посредницима и добијати одговоре од сервера.
- Могућност кеширања: Неки одговори се чувају код посредника или клијента ради побољшања времена одговора.
- Код на захтев: Сервери привремено прилагођавају или проширују функционалност клијента слањем софтверског програмског кода на клијента.
Предности REST-а
- Скалабилност: REST API-ји су познати по својој скалабилности, јер оптимизују интеракције између клијента и сервера. Кеширање и дизајн без стања су кључне карактеристике које смањују оптерећење сервера.
- Флексибилност: RESTful API-ји нуде потпуно раздвајање клијента и сервера. Такве услуге раздвајају и поједностављују различите компоненте сервера, омогућавајући им независтан развој.
- Независност: Можете писати серверске и клијентске апликације на различитим програмским језицима, без утицаја на дизајн API-ја.
Случајеви употребе REST-а
- Веб API-ји
- Веб сервиси
- Архитектура микросервиса
Шта је gRPC?
gRPC је оквир за даљинско позивање процедура (Remote Procedure Call – RPC), који може да ради у било ком окружењу. Овај оквир отвореног кода је дизајниран као протокол високих перформанси, који ефикасно повезује услуге у и изван центара података.
Клијентска апликација може да позове метод на серверској апликацији на другом рачунару, као да је реч о локалном објекту. Користећи gRPC, дефинишете услугу и методе које се могу позвати на даљину, заједно са њиховим параметрима и типовима повратних вредности.
gRPC има подршку за проверу здравља, аутентификацију, балансирање оптерећења и праћење. Овај оквир користи HTTP/2 и протоколске бафере за пренос података. Приликом размене података, позива се процедура, а не URL адреса ресурса.
Предности gRPC-а
- Скалабилност: gRPC омогућава инсталирање окружења за извршавање једном командом и скалирање на милионе RPC-а у секунди.
- Једноставна дефиниција услуге: Користите протоколске бафере да дефинишете своје услуге и покренете их.
- Вишеплатформност: Овај оквир генерише клијентске и серверске кодове за различите платформе и језике.
- Двосмерни стриминг и интегрисана аутентификација.
Случајеви употребе gRPC-а
- Веб API-ји
- Веб сервиси
- Апликације за стриминг
- Комуникација микросервиса
Сличности између REST-а и gRPC-а
- Механизам размене података: Оба архитектонска дизајна омогућавају серверима и клијентима размену података. Ови подаци се деле према одређеним правилима.
- Погодни за скалабилне и дистрибуиране системе: Асинхрона комуникација и дизајн без стања, које поседују и REST и gRPC, олакшавају скалирање њихових API-ја.
- Коришћење HTTP комуникације: Оба користе HTTP, најпопуларнији комуникациони протокол на вебу.
- Флексибилност: Можете користити REST и gRPC са различитим програмским језицима и технологијама.
REST vs. gRPC: Детаљно поређење
REST и gRPC услуге се разликују на следеће начине:
Размена података
У REST API-јима, подаци који се преносе између софтверских компоненти обично су у JSON формату. JSON се мора серијализовати и превести у програмски језик за размену података. Међутим, REST API-ји такође могу размењивати податке у форматима као што су HTML и XML.
gRPC по дифолту користи формат протоколских бафера. Међутим, изворно подржава и JSON. Протоколски бафери нису читљиви за људе. Сервер користи језик описа интерфејса протоколских бафера да дефинише структуру података. gRPC затим серијализује структуру података у бинарни формат. После тога ће десеријализовати податке у било који одговарајући програмски језик.
Комуникациони модел
У REST-у, клијент шаље један захтев серверу, а сервер затим шаље један одговор као повратну информацију. Клијент мора сачекати одговор сервера пре него што настави са радом. Ово је модел захтев-одговор.
У gRPC-у, клијент може послати један или више захтева серверу, што резултира једним или више одговора. Подаци се могу преносити у више-према-више, више-према-један, један-према-више или један-на-један везама. gRPC користи модел комуникације клијент-одговор.
Генерисање кода
gRPC има уграђене функције за генерисање кода на страни сервера и клијента. Ове функције су доступне на различитим језицима захваљујући компајлеру Протоцол Buffers. gRPC генерише код на страни сервера и клијента након дефинисања структуре у .proto датотеци.
REST нема уграђене функције за генерисање кода. Ако вам је потребна ова функција, можете користити алате треће стране.
HTTP протокол
REST API-ји користе HTTP/1.1. Да бисте послали захтев REST сервису, потребна вам је URL адреса ресурса. HTTP/1.1 шаље информације између рачунара и веб сервера. URL ресурса у REST сервису је видљив клијенту. Дизајнери API-ја контролишу структуру URL-ова ресурса.
gRPC користи HTTP/2. Ова верзија HTTP-а је уведена 2015. године и користи се у прегледачима као што су Internet Explorer, Safari и Chrome. За разлику од HTTP/1.1, који све држи у обичном тексту, овај новији формат користи енкапсулацију бинарног формата, што резултира већим бројем опција за испоруку података и убрзава цео процес.
Структура података корисног терета
REST користи XML или JSON за слање и примање података. JSON је најчешће коришћени формат за слање динамичких података у REST-у, јер је флексибилан и не захтева никакву структуру. JSON подаци су такође читљиви за људе. Једини проблем са JSON-ом је што није тако брз, јер мора бити серијализован и преведен током преноса података.
gRPC користи протоколске бафере за серијализацију корисног терета. Ово је високо компримовани формат који смањује количину података у порукама. Овај оквир користи Protobuf да аутоматски конвертује снажно типизиране поруке у програмске језике клијента и сервера.
Подршка за претраживаче
REST је подржан на свим прегледачима, јер користи HTTP/1.1. То га чини савршеним избором за веб услуге и API-је.
gRPC има ограничену подршку за претраживаче, јер је заснован на HTTP/2. Да бисте подржали све прегледаче, морате додати gRPC-web као прокси слој. Из тог разлога, gRPC се углавном користи за интерне системе.
Повезивање клијент-сервер
REST је лабаво повезан архитектонски дизајн. То значи да клијент и сервер не морају да знају имплементације једни других. Ова карактеристика олакшава развој RESTful API-ја током времена, јер не морате мењати клијентски код када мењате дефиниције сервера.
gRPC је чврсто повезан оквир где сервер и клијент морају имати приступ истој .proto датотеци. Ако је потребно извршити било какве промене у датотеци, морате ажурирати и сервер и клијента.
REST у односу на gRPC
| Карактеристика | REST | gRPC |
| HTTP протокол | HTTP/1.1 | HTTP/2 |
| Подршка за прегледаче | Подржава све прегледаче користећи HTTP/1.1 | Мања подршка за прегледаче због коришћења HTTP/2 |
| Генерисање кода | Користе се алати треће стране | Уграђене функције за генерисање кода |
| Приступ дизајну | Дизајн оријентисан на ентитете | Дизајн оријентисан на услуге |
| Комуникациони модел | Један клијент комуницира са једним сервером | Вишеструки модели комуникације, нпр. један клијент шаље захтеве више сервера, један сервер комуницира са више клијената |
| Сложеност | Уобичајени REST софтвер потребан само на страни клијента или сервера | gRPC софтвер потребан и на страни клијента и сервера |
Када користити REST
RESTful API-ји и веб сервиси су веома популарни. RESTful сервиси су једноставни за имплементацију, структурирају податке, флексибилни су и читљиви. Можете користити REST у следећим случајевима:
- Архитектуре засноване на вебу: Можете да креирате веб, мобилне и мултиплатформске API-је користећи REST архитектонски дизајн.
- Једноставна комуникација података: REST користи JSON, формат података који се лако чита.
- API-ји за јавност: Ако намеравате да јавност користи податке и ваш API, REST ће бити добар избор због читљивости.
Када користити gRPC
gRPC није толико популаран као RESTful сервиси. Међутим, има јединствене карактеристике које га издвајају у следећим апликацијама:
- Вишејезични системи: gRPC одговара архитектури микросервиса писаних на различитим програмским језицима, где су промене API-ја ретке.
- Микросервисне везе: Карактеристике попут двосмерног стриминга и слабије подршке за прегледаче чине gRPC добром опцијом за интерне API-је.
- Мреже за стриминг у реалном времену: gRPC можете користити са интерним услугама које обрађују велике количине података и захтевају стриминг у реалном времену.
Мишљење аутора
Иако gRPC има специфичне карактеристике које могу бити корисније од REST-а у апликацијама као што је Интернет ствари, REST је бољи избор због своје читљивости, флексибилности и широке примене. Слабија подршка gRPC-а за прегледаче га чини мање погодним за програмере који праве веб услуге.
Универзална подршка за RESTful услуге чини REST идеалним архитектонским стилом API-ја за интеграције веба и микросервиса.
Закључак
REST и gRPC су међу многим архитектонским стиловима API-ја које можете одабрати за израду вашег следећег API-ја. Коначни избор ће зависити од производа који желите да направите. RESTful сервиси ће бити одлични за израду API-ја за јавност, док је gRPC бољи избор за услуге као што су мобилне апликације које не захтевају подршку за прегледаче.
Прочитајте и наш чланак о томе како креирати gRPC од нуле користећи Java.