Під час взаємодії з API, ви часто зустрічаєтеся з REST та gRPC. Хоча 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 проти gRPC: глибоке порівняння
Сервіси REST та gRPC розрізняються за такими параметрами:
Обмін даними
У REST API дані, що передаються між програмними компонентами, зазвичай подаються у форматі JSON. JSON потрібно серіалізувати та перевести у відповідну мову програмування для обміну даними. Однак API Rest також можуть передавати дані у форматах HTML та XML.
gRPC за замовчуванням використовує формат буферів протоколу. Але він також підтримує JSON. Буфери протоколів не читаються безпосередньо людиною. Сервер використовує мову опису інтерфейсу буфера протоколу для визначення структури даних. Далі gRPC серіалізує структуру даних у бінарний формат. Потім він десеріалізує дані у будь-які вказані мови програмування.
Комунікаційна модель
У REST клієнт відправляє один запит на сервер, а потім сервер надсилає відповідь у відповідь. Клієнт повинен дочекатися відповіді сервера, перш ніж продовжувати роботу. Це модель “запит-відповідь”.
У gRPC клієнт може надіслати один або кілька запитів до сервера, що призводить до отримання однієї або кількох відповідей відповідно. З’єднання даних можуть бути “багато-до-багатьох”, “багато-до-одного”, “один-до-багатьох” або “один-до-одного”. gRPC використовує модель зв’язку клієнт-відповідь.
Генерація коду
gRPC має вбудовані функції генерації коду для сервера та клієнта. Ці можливості доступні для різних мов завдяки компілятору Protocol Buffers. gRPC генерує код на стороні сервера та клієнта після визначення структури у протофайлі.
REST не має вбудованих функцій генерації коду. Для цієї функції вам потрібно використовувати сторонні інструменти.
Протокол HTTP
REST API використовують HTTP 1.1. Щоб відправити запит до служби REST, потрібна URL-адреса ресурсу. HTTP 1 передає інформацію між комп’ютером і веб-сервером. URL-адреса ресурсу в службі REST є видимої для клієнта. Розробники API контролюють структуру URL-адрес ресурсів.
gRPC використовує HTTP/2. Ця версія HTTP була представлена в 2015 році та застосовується в таких браузерах, як Internet Explorer, Safari та Chrome. На відміну від HTTP/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 – це тісно пов’язаний фреймворк, де сервер і клієнт повинні мати доступ до одного протофайлу. Якщо потрібно внести зміни до файлу, також потрібно оновити сервер і клієнт.
REST проти gRPC
| Функція | REST | gRPC |
| Протокол | HTTP 1.1 | HTTP/2 |
| Підтримка браузера | Підтримує всі браузери, оскільки використовує HTTP 1.1 | Обмежена підтримка браузерів, оскільки використовує HTTP/2 |
| Генерація коду | Використовує сторонні інструменти | Вбудовані функції генерації коду |
| Підхід до дизайну | Об’єктно-орієнтований дизайн | Сервіс-орієнтований підхід |
| Доступ до даних | URL-адреси ресурсів | Виклики служб |
| Двонаправлена потокова передача даних | Недоступно | Доступно |
| Реалізація | Для реалізації 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 ідеальним архітектурним стилем для веб-інтеграції та мікросервісів.
Висновок
REST та gRPC є двома з багатьох архітектурних стилів API, які ви можете вибрати при розробці вашого наступного API. Остаточний вибір залежить від продукту, який ви плануєте створити. RESTful сервіси ідеально підходять для створення загальнодоступних API, тоді як gRPC є хорошим вибором для сервісів, таких як мобільні застосунки, що не потребують підтримки браузера.
Ознайомтеся також з нашою статтею про створення gRPC з нуля, використовуючи Java.