REST или gRPC: кога кое да изберете и защо основната ви система не говори нито един от двата

Въпросът «REST или gRPC?» обикновено се поставя така, сякаш трябва да се избере лагер за цялата архитектура. На практика почти никога не се решава веднъж: решава се на всяка граница. API, което получават външни страни, едно извикване между две услуги на един и същ екип и връзката със система на двайсет години искат различни отговори.

Това е продължение на клона «онлайн» от нашата статия за онлайн или асинхронно: там се решава кога е удобно да се отговаря веднага, а тук — с какъв протокол да се направи това и какво да се прави, когато системата в дъното не може.

Статията е за техническия екип, който трябва да взема тези решения: архитекти, ръководители на разработката и хората, които интегрират системи в банки, застрахователни компании, финтех компании или търговски вериги. Предлага критерий, който се побира в едно изречение:

REST на границата, gRPC в сърцевината, адаптер за наследената система.

Това е критерий, не правило; в края са описани случаите, в които си струва да се наруши.

Какво е gRPC, в пет идеи

gRPC е рамка за отдалечено извикване на процедури (RPC). Вместо да се мисли за ресурси и URL адреси, се мисли за услуги с методи, които се извикват от разстояние, сякаш са локални. Определят го пет идеи:

1. Първо е договорът. Услугата и нейните съобщения се описват във файл .proto. По подразбиране gRPC ползва Protocol Buffers (Protobuf) като език за дефиниране на интерфейси, както за услугата, така и за структурата на съобщенията [1]. От .proto се генерират типизираните клиент и основата на сървъра на езиците, които ползва екипът [4].
2. Върви върху HTTP/2 и пътува в двоичен вид. gRPC е проектиран за HTTP/2, който предлага двоично пакетиране, компресия и мултиплексиране на няколко извиквания върху една TCP връзка. Protobuf произвежда малки съобщения и се сериализира бързо. Нюанс, който не бива да се губи: HTTP/2 не е само за gRPC; и HTTP API с JSON може да го ползва [4].
3. Streaming от първа класа. Освен простото извикване (една заявка, един отговор) има streaming от сървъра към клиента, от клиента към сървъра и двупосочен. gRPC гарантира реда на съобщенията в рамките на едно и също извикване [1]. Подходящ е за телеметрия, котировки на живо или известия.
4. Изрични срокове (deadlines). Клиентът посочва колко е готов да чака; ако срокът изтече, извикването завършва с грешката DEADLINE_EXCEEDED [1]. По подразбиране gRPC не определя никакъв срок, така че клиентът може да остане да чака практически завинаги [2]. Когато срокът изтече, gRPC отменя извикването, но приложението трябва да открие тази отмяна и да спре работата, която е стартирало [2]. Срокът може да се предава нататък към извикванията, които услугата прави към други, за да не се хабят ресурси за отговор, който вече никой не чака [2][4].
5. Състояния на грешка със собствен речник. Всяко извикване завършва със статусен код от каталог от 17 стойности, между които INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, UNAUTHENTICATED, RESOURCE_EXHAUSTED и UNAVAILABLE [3]. Официалната страница с кодовете не определя съответствие с HTTP кодовете. Който излага услугата навън, трябва да реши този превод писмено.

gRPC не е «по-бърз REST»: това е друг модел, със задължителен договор и строга спецификация, която според Microsoft избягва спора за формата на URL адресите, глаголите и кодовете на отговорите [4]. Ако освен това ще се излага HTTP/JSON, тези маршрути, глаголи и грешки пак трябва да се определят. И не е безплатно: двоичният формат не се чете на око и за да се тълкува, е нужен договорът [4].

Кога REST

REST е стил на проектиране върху HTTP, ориентиран към ресурси, глаголи и представяния, почти винаги в JSON. Той е изборът по подразбиране на границата: там, където вашата система се среща с онези, които не контролирате.

• Външни страни и интегратори. Който ползва вашето API, няма причина да възприема вашия инструмент за генериране на код. REST/JSON намалява зависимостта от генерирани SDK и улеснява проверката и ръчните тестове; партньор може да изпробва едно извикване с curl за минута.
• Frontend в браузъра. Нито един браузър не дава контрола върху HTTP/2, от който gRPC има нужда, затова услуга gRPC не може да се извиква директно от една страница [4]. По-нататък се вижда какво да се направи, когато въпреки това искате gRPC в уеб.
• Отстраняване на грешки от човек. Една REST заявка се чете, копира, поставя в тикет и се възпроизвежда. С gRPC са нужни инструменти, които разбират формата [4].

Кога gRPC

Помислете за gRPC, когато вие контролирате и доставчика, и потребителя, приемате да управлявате файловете .proto и имате измерено ограничение за латентност, размер на съобщението или обем. Сценариите, които документацията на Microsoft препоръчва, са микроуслуги с ниска латентност и висока производителност, комуникация в реално време от точка до точка, среди с няколко езика, мрежи с ограничена честотна лента и комуникация между процеси на една и съща машина [4].

• Вътрешни услуги. Между услуги от един и същ домейн на доверие силният договор и генерираният клиент избягват цяла категория грешки: полета, които сменят името си, типове, които се тълкуват различно, клиенти, писани на ръка, които се разминават.
• Силен договор между екипи. Когато няколко екипа и езика споделят услуги, .proto служи като изпълнимо споразумение: ако не се компилира, не се интегрира.
• Обем. Когато се правят много малки извиквания, размерът на съобщението и мултиплексирането върху една връзка си личат. Измерете с вашето натоварване, преди да оправдаете промяната със скоростта.
• Streaming. Ако случаят на употреба е поток (цени, събития от устройства, напредък на дълъг процес), gRPC го предлага като част от договора, не като добавка.

Има един случай, който Microsoft изключва: масовото разпращане към много свързани клиенти; gRPC няма понятието «broadcast» и всяко извикване предава отделно [4].

Браузърът и gRPC-Web

Тъй като браузърът не може да говори роден gRPC, съществува gRPC-Web: адаптиран протокол с генериран клиент на JavaScript и съвместим прокси (официалният урок ползва Envoy) между браузъра и gRPC услугата; освен това може да изисква настройка на CORS [5].

Има ограничения, които е добре да се знаят, преди да се реши. В хранилището на проекта streaming от сървъра към клиента се поддържа само в режим grpcwebtext, а streaming от клиента и двупосочният не се поддържат [6]. Microsoft го нарежда сред причините да се предпочете друга рамка, когато API трябва да е достъпно от браузър: gRPC-Web предлага поддръжка, но с ограничения и с допълнително сървърно прокси [4].

Практическо правило: gRPC-Web, ако уеб приложението е ваше и платформата вече ползва Protobuf; REST/JSON, ако ще го ползват външни страни.

Как да изложите gRPC като REST, без да пишете логиката два пъти

Не е нужно да се избира между двете лица. Договорът .proto може да носи HTTP анотации (google.api.http), които казват кой маршрут и глагол отговарят на всеки метод. Междинен компонент, обикновено gateway-ът или прокси, превръща HTTP/JSON заявката в gRPC извикване и връща отговора в JSON. Този механизъм се нарича транскодиране (transcoding) [4][7][18]:

REST клиент  → gateway (транскодиране) → gRPC услуга → адаптер → наследена основна система
gRPC клиент  ──────────────────────────→ gRPC услуга → адаптер → наследена основна система

Два примера за gateway-и, които го предлагат, като категория, а не като препоръка:

• Envoy има филтъра gRPC-JSON transcoder, който позволява на REST клиент с JSON да изпраща заявки по HTTP, а те да се пренасочват към gRPC услуга. Изисква се да се познава дескрипторът на Protobuf на услугата и HTTP анотациите в договора [7].
• Apache APISIX има плъгина grpc-transcode, който преобразува заявки и отговори между HTTP и gRPC. Файловете proto се регистрират през неговия административен API, като текст или като двоичен дескриптор [8]. Консултираната документация не споменава streaming; проверете във вашата версия.

Идеята: една-единствена имплементация, два начина да се извиква.

Две внимания, които транскодирането не решава само:

• Грешки. Конверторът превежда кодове, но политиката какво значи всеки от тях за външна страна определяте вие. Един вътрешен UNAVAILABLE показва ли се като грешка «услугата не е достъпна», или първо се повтаря?
• Сигурност. Автентикацията, фината авторизация и квотите са грижа на gateway-а и на услугата, не на формата.

Инструменти за тестване: кои са още актуални

Ръчното тестване на gRPC услуга изисква инструмент, който разбира Protobuf. Това е състоянието, което проверихме на 6 октомври 2026 г.; всяка по-късна промяна може да го измени.

Рефлексията на сървъра позволява откриването на методи без .proto, но трябва да се включи в услугата и в продукция е добре да се реши на кого се показва.

Java: Spring Boot и Quarkus

Java е полезен случай, защото и двете рамки имат документиран път към gRPC. Версиите по-долу са проверените на 6 октомври 2026 г.

Spring Boot. Spring gRPC е официален проект на Spring с версия 1.0.0, публикувана на 4 декември 2025 г. Към датата на проверката най-новата стабилна версия в GitHub е 1.1.1 (21 август 2026 г.) [15]. Версия 1.1.0 (10 юни 2026 г.) прехвърли автоконфигурацията към Spring Boot 4.1.0, а клоновете 1.0.x сочат към Boot 4.0 [15]. За нова основа със Spring Boot 4.1 има официален път; с по-ранни версии проверете съвместимостта с линията 1.0.x.

Quarkus. gRPC се добавя с разширението quarkus-grpc: имплементира и ползва услуги, генерира код от .proto, интегрира се с реактивния модел, поддържа TLS и взаимен TLS, xDS и комуникация в процеса [16]. Quarkus препоръчва gRPC сървъра, базиран на Vert.x, защото е по-гъвкав и по-добре интегриран в екосистемата, и този сървър може да обслужва HTTP и gRPC през един и същ порт, ако се настрои quarkus.grpc.server.use-separate-server=false [16]. В Maven Central последната версия 3.x на разширението към датата на проверката е 3.40.1 (30 септември 2026 г.); има и 4.0.0.Beta1 от същия месец, която е предварителна версия [16].

И двете работят: решава рамката, която екипът вече владее.

Каквато и да е рамката, важат същите практики: едно-единствено хранилище за договорите, интерсептори за идентичност и трасиране, обща политика за грешките, проверки за състояние (health checks) и задължителни срокове във всеки клиент.

Еволюция на договорите Protobuf: как да не счупите никого

Договорът е продуктът. Ако се променя без внимание, чупи клиентите, които не са разбрали. Официалното ръководство на Protobuf определя ясни правила [17]:

• Добавянето на полета е безопасно. Старият код пренебрегва новите полета при четене, а новият ползва стойности по подразбиране със стари съобщения.
• Добавянето на стойности към enum е безопасно в двоичния формат; въпреки това проверете дали клиентите и бизнес правилата отчитат новата стойност (в езици със затворени enum, като Java, неизвестна стойност пристига като отделен случай).
• Номерът на поле не се сменя и не се използва повторно, щом съобщението е в употреба, защото този номер идентифицира полето в двоичния формат.
• Когато се премахва поле, номерът му се резервира (и, ако се ползва JSON, също и името му), за да не го използва някой повторно по погрешка.
• Преместването на полета към или от съществуващ oneof е рисковано: може да се загуби информация при сериализиране и четене.

Ръководството за проектиране на API на Google важи както за REST, така и за RPC и препраща към своите предложения AIP-180 (съвместимост) и AIP-185 (версии) [18]. Оперативното правило е кратко:

1. Публикувайте файловете .proto като версиониран продукт.
2. Проверявайте съвместимостта в непрекъснатата интеграция (с инструмент за откриване на промени, които чупят).
3. Поддържайте тестове за договор между услугата и нейните потребители.
4. Третирайте всяка промяна, която не е само добавяне, като нова версия на API, с период на съвместно съществуване.

Защо основната ви система не говори нито един от двата

Тук е точката, която почти никое сравнение на протоколи не засяга. Централните системи на една застрахователна компания, банка или търговска верига с десетилетия история обикновено не говорят нито REST, нито gRPC, а техните ограничения обясняват защо:

• Не излагат API, които могат да се извикват, и не известяват, когато нещо се промени.
• Приемат данни само в зона за обмен, таблици или файлове, и ги обработват със собствено темпо, често на пакети, като пускат собствен процес.
• Издържат малко натоварване: серия от онлайн извиквания ги задръства.
• Отговорът идва, когато процесът приключи, не когато заявката е изпратена, а понякога се намира само като се прочете отново друга таблица или файл.

Изборът на REST или gRPC за горния слой не променя това. Нужно е нещо по средата — адаптер: компонент, който говори езика на основната система навътре и новия договор навън. А когато моделът, грешките, сигурността или транзакциите от двете страни не съвпадат, адаптерът трябва да е антикорупционен слой (anti-corruption layer), патернът, който Eric Evans описва в Domain-Driven Design [19].

Това е фасада между подсистеми, които не споделят семантика, така че външните зависимости да не ограничават проектирането на приложението; може да е вътрешен компонент или самостоятелна услуга [19].

Разликата с прокситото е важна:

Четири задачи обикновено падат върху адаптера и е добре да се запишат, преди да се размият в кода (критерий за проектиране; самият патерн е описан в [19]):

• Превеждане на обектите с данни и проверка на инварианти на тази граница, включително санитизиране на входните данни.
• Нормализиране на грешките: собствен код за връщане или ред в таблица с грешки става gRPC състояние, а оттам, ако е уместно, HTTP код, с изричната политика, за която стана дума по-горе.
• Защита на основната система. Тя има темпо, което издържа. Ако масово издаване изпрати хиляди движения, а основната система обработва десетки в минута, онлайн извикването не е начинът да ги предадете: нужна е опашка или механизъм за изравняване на натоварването [20], освен ако извикващият не изисква синхронен отговор с ниска латентност. Опашката изисква да се определят идемпотентност, повторни опити, обработка на неуспешните съобщения, ред, когато е приложимо, и справка за състоянието по идентификатор за корелация [20]. Това е темата на следващата статия от тази поредица.
• Наблюдение: идентификатор за корелация във всяко извикване, за да може да се възстанови какво е станало между новия договор и основната система, и структурирани записи за диагностика на грешки при превода.

Цени: повече латентност, още една услуга за експлоатация и решението дали слоят е постоянен [19]. Microsoft препоръчва да се ограничи до превеждане и да не концентрира бизнес правила или оркестрация [19].

Таблица за решение

Кога да нарушите водещото изречение

«REST на границата, gRPC в сърцевината, адаптер за наследената система» е добра отправна точка. Има разумни случаи, в които си струва да се отклоните:

• Всичко REST. С малък екип, умерен обем и без streaming Protobuf може да струва повече, отколкото дава.
• gRPC до границата. Ако външните потребители са малко и приемат генерирани SDK, се избягва един слой.
• Без адаптер. Ако основната система вече предлага модерно и стабилно API, адаптерът се свежда до тънко съпоставяне.
• Асинхронно вместо синхронно. Ако проблемът е темпото на основната система, а не протоколът, помага опашка, събитие или callback с идентификатор за корелация.

Онова, което си струва да се запази: да се решава за всяка граница, да се измерва, преди да се оправдава, и да се пише договорът, преди да се пише кодът.

Заключение: какво да вземете със себе си на следващата среща

Преди да изберете протокол, три въпроса подреждат дискусията: кой ползва интерфейса и кой контролира неговите клиенти, какъв език говори системата в дъното и какво темпо издържа. Ако системата в дъното не говори нито един от двата или е по-бавна от онзи, който я извиква, а измереното натоварване изисква входът да се отдели от обработката, най-разумно е да се даде приоритет на адаптера и да се обмисли опашка, преди да се сменя протоколът.

Какво прави Hábil

Hábil работи в пространството между съществуващите системи и новите слоеве: стреми се основна система, която не говори нито REST, нито gRPC, да може да обслужва вашите канали и партньори, без да спира операцията. За обединяването на API и канали вижте страницата Обединяване на дейността и каналите; за обновяването на основната система в нейно темпо — Модернизиране на основната система без спиране на бизнеса. Първият разговор е безплатен: тръгва от картата на вашите интеграции и от точките, където един договор или една основна система с ограничено темпо биха могли да ви струват пари, време или доказателства. Пишете ни в WhatsApp.

Консултирани на 6 октомври 2026 г. Версиите и датите на инструментите и проектите се променят; отбелязаните с [доставчик] са цифри или състояния, които публикува самият доставчик.