Ви часто стикаєтеся з REST і gRPC під час роботи з API. Незважаючи на те, що Rest домінує в цій галузі протягом багатьох років, gRPC виявляється гідним конкурентом.
Rest і gPRC — це два різні способи розробки API. API діють як зв’язковий міст між службами, які можуть представляти складні системи, розташовані на різних комп’ютерах або написані різними мовами.
Ця стаття представить як Rest, так і gRPC, розповість про їх схожість, відмінності та де їх використовувати.
Що таке відпочинок?
Відпочинок (Representational State Transfer) — це архітектурний програмний підхід, який диктує правила обміну даними між програмними компонентами. Решта базується на стандартному веб-протоколі зв’язку HTTP.
Усі API, засновані на архітектурному стилі REST, називаються RESTful API. З іншого боку, веб-сервіси з архітектурою REST відомі як веб-сервіси RESTful.
Архітектурний стиль REST керується цими принципами;
- Уніфікований інтерфейс: сервер повинен передавати дані в стандартному форматі. Однак передані дані можуть бути у форматі, відмінному від внутрішнього представлення ресурсу серверної програми.
- Без громадянства: сервер повинен виконувати кожен запит клієнта незалежно, незалежно від попередніх запитів. Запити клієнтів на ресурси можуть бути в будь-якому порядку, і кожен запит ізольований від решти.
- Багаторівнева система: представляє рівень авторизованих посередників між сервером і клієнтом. Клієнт може з’єднатися з цими авторизованими посередниками та все одно отримувати відповіді від сервера.
- Можливість кешування: деякі відповіді зберігаються в посередника або клієнта для покращення часу відповіді.
- Код на вимогу: сервери тимчасово налаштовують або розширюють функціональні можливості клієнта, передаючи код програмного забезпечення клієнту.
Переваги REST
- Масштабованість: REST API відомі своєю масштабованістю, оскільки вони оптимізують взаємодію клієнт-сервер. Кешування та відсутність стану є основними функціями, які зменшують навантаження на сервер.
- Гнучкість: API RESTful пропонують повне розділення клієнт-сервер. Такі сервіси відокремлять і спростять різні серверні компоненти, які можуть розвиватися незалежно.
- Незалежність: ви можете писати серверні та клієнтські програми на різних мовах програмування, не впливаючи на дизайн 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. Буфери протоколів не читаються людиною. Сервер використовує мову опису інтерфейсу буфера протоколу для визначення структури даних. Потім gPRC серіалізує структуру даних у двійковий формат. Потім він десеріалізує дані на будь-які вказані мови програмування.
Комунікаційна модель
У 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 — це тісно пов’язаний фреймворк, де сервер і клієнт повинні мати доступ до одного протофайлу. Якщо вам потрібно внести будь-які зміни у файл, ви також повинні оновити сервер і клієнт.
Відпочинок проти gRPC
ФункціяПротокол RESTgRPCHTTPHTTP 1.1HTTP 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 у таких програмах, як Інтернет речей, останній виграє завдяки своїй читабельності, гнучкості та широкому застосуванню. Низька підтримка браузера gRPC робить його не дуже вдалим вибором для розробників, які хочуть створювати веб-сервіси.
Універсальна підтримка служб RESTful робить REST ідеальним стилем архітектури API для веб-інтеграції та мікросервісів.
Висновок
REST і gRPC є одними з багатьох архітектурних стилів API, які ви можете вибрати під час створення свого наступного API. Остаточний вибір залежатиме від продукту, який ви хочете створити. Сервіси RESTful ідеально підійдуть для створення загальнодоступних API, тоді як gRPC є хорошим вибором для таких сервісів, як мобільні програми, які не потребують підтримки браузера.
Далі перегляньте нашу статтю про те, як створити gRPC з нуля за допомогою Java.