gRPC vs REST
Привет! Я Альбина Гараева - senior-системный аналитик с 9-летним опытом. Недавно в своем телеграм-канале я рассказывала про gRPC, а сегодня предлагаю поразмыслить о муках выбора между gRPC и REST.
Для начала давайте вспомним что такое gRPC, и что такое REST:
REST (Representational State Transfer) – это архитектурный стиль, который определяет правила обмена данными между компонентами распределенного приложения в сети. REST основан на стандартном протоколе HTTP.
gRPC - это система удаленного вызова процедур, с открытым исходным кодом. То есть клиентское приложение может вызвать метод серверного приложения на другой машине, как если бы это был локальный объект. В качестве транспорта использует протокол HTTP/2.
Что выбрать?
В наше время когда перед пользователем встает выбор того или иного, он сразу идет в великий и могучий гугл в поисках информации и статей по интересующей его теме. И это нормально, так как чтобы принять решение, нужно собрать информацию и проанализировать её.
Если вы попробуете поискать информацию про gRPC и REST, вы найдете огромное количество статей на эту тему, но в большинстве своем они подходят к сравнению чисто с технической стороны и просто кричат, я бы даже сказала вопят, что gRPC или REST "быстрее, выше, сильнее".
Опуская при этом важную деталь, на которой я хотела бы сегодня сделать акцент - ЦЕЛЬ.
Для каких целей стоит использовать gRPC или REST? Ведь если подходить к этому вопросу только с одной стороны, то может получиться ситуация, когда вы будете палить по воробьям из пушки.
Итак, для начала давайте определим основные параметры на которые мы будем ссылаться при рассмотрении наших целей.
Мы выберем 3 основных параметра, а именно:
- Структура данных
- Коммуникация
- Пропускная способность
Структура данных
В gPRC используются буферы протокола для сериалиазции данных. Этот фреимворк использует Protobuf для автоматического преобразования сильно типизированных сообщении в языки программирования клиента и сервера.
Преимущества данного подхода:
- Сильная типизация - это исключает ошибки с неверным переданными типами данных.
- Генерация клиентского кода - протокол автоматически генерирует клиентский код для различных языков программирования, что упрощает интеграцию с клиентами.
В REST API чаще всего в качества формата данных используются JSON и ХМL, но также могут использоваться другие форматы.
Преимущества данного подхода:
- Универсальность - помимо популярных форматов данных JSON или XML, можно передавать данные в любом формате.
- Простота чтения - данные, переданные в формате JSON, легко читаемы.
Коммуникация
В REST API клиент на каждый необходимый ему ресурс отправляет запрос и должен дождаться ответа от сервера. При этом в запросе используются стандартные методы HTTP: POST, GET, PUT, DELETE.
Особенность данного подхода:
- Простота проектирования - создание и использование HTTP API относительно просто.
- Доступность отладки - HTTP API более прозрачны и их легче отлаживать с использованием инструментов, таких как браузерные расширения или утилиты наподобие cURL.
- Свободная связь - клиент и сервер не должны знать о реализации друг друга.
В gRPC поддерживается потоковая передача данных, когда клиент может отправить серверу множество сообщений и получить один или несколько ответов. Также поддерживается двунаправленная передача данных.
Преимущества данного подхода:
- Возможность передавать потоки данных.
- Мультиплексирование (в HTTP 1.1 для передачи трех файлов надо установить три соединения, в каждом из которых будет запрашиваться и отправляться определенный файл. В HTTP/2 можно все передать по одному соединению).
- Сильная связность - клиент и сервер должны иметь доступ к одному и тому же фаилу proto. Если вам нужно внести какие-либо изменения в этот фаил, вы должны также обновить сервер и клиент.
Пропускная способность
Вот мы добрались и до 3-его параметра - пропускная способность. В интернете очень много споров по поводу скорости передачи данных при использовании gRPC и REST API. На мой взгляд это сильно зависит от знаний и опыта команды разработки в той или иной технологии, поэтому мы посмотрим на эти технологии без привязки к этому.
В REST API, как я говорила, чаще всего используется JSON, который необходимо сериализовать и транслировать во время передачи данных. Что в свою очередь влияет на скорость передачи данных.
В gRPC используются буферы протокола для сериализации данных полезной нагрузки. Это сильно сжатый формат данных, вследствие чего уменьшается размер сообщений и ускоряется работа.
Цели
Давайте рассмотрим несколько простых примеров, с которыми каждый из вас когда-нибудь сталкивался или столкнется.
Пример №1
Представим, что у нас есть задача небольшой командой реализовать сервис по выдаче кредитного отчета пользователю по запросу.
Данный сервис планируется использовать на различных платформах.
Итак, наши цели:
1. Получить данные по запросу
2. Данные содержат большой объем информации
3. Данные передаются в одном запросе
4. API должно быть простым и доступным для остальных команд
Посмотрев на рассмотренные параметры, можно понять, что в этом случае нам лучше всего подойдет REST, так как не смотря на большой объем данных, он прост в реализации и для него не требуются сильная связанность между клиентом и сервером, значит остальные команды смогут спокойно использовать наш сервис в своих целях.
Пример №2
Теперь нашей команде дали задачу реализовать сервис чата. Который должен в реальном времени принимать и передавать сообщения между пользователями. Сообщения могут приходить с разных платформ и должны иметь единый формат.
Итак, наши цели:
1. Потоковое получение и возврат данных
2. Данные должны быть в едином формате
3. Сервер должен иметь возможность отправить данные клиенту сразу
4. Низкая задержка при получении новых сообщений
И снова, если взглянем на наши параметры, которые мы определили для наших технологий, мы поймем, что в этом случае gRPC - лучший выбор. Т в данном случае нужна высокая производительность и строгая типизация данных.
* * *
Исходя из рассмотренных выше примеров, каждая из представленных технологий имеет ряд преимуществ и подходит для решения определенных целей.
Да, несомненно, REST API на данный момент более распространенный подход к реализации API - интерфейсов. Но все же при выборе той или иной технологии надо в первую очередь исходить из целей. Не факт, что технология, использованная на одном проекте, также хорошо будет работать и в вашем.
P.S. Ловите шпаргалку по часто сравниваемым параметрам REST и gRPC.