HTTP или gRPC: какой API подойдет вашему проекту

Приложения и микросервисы становятся все сложнее и масштабнее. Растут и требования к эффективной передаче данных, ведь API может стать «бутылочным горлышком», которое затормозит развитие всего проекта.

Трудно представить современное приложение, которое не будет взаимодействовать с другими решениями. Поэтому выбор правильного способа создания API — одна из ключевых задач для разработчиков.
В статье сравним протоколы HTTP и gRPC, их основные характеристики, преимущества и сферы применения. 

Быстрое сравнение HTTP и gRPC

Разберем основы HTTP и gRPC. Это поможет лучше понять контекст их использования. Далее подробно рассмотрим каждый протокол.

HTTP

Универсальность

HTTP API — гибкое решение, способное взаимодействовать с разными клиентами, включая браузеры, мобильные приложения и множество других систем.

Относительная простота

Создание и использование HTTP API относительно просто, особенно если сравнивать с gRPC. Также многие языки программирования имеют библиотеки для работы с HTTP.

Поддержка стандартных методов

HTTP API легко работают со стандартными HTTP-методами: GET, POST, PUT, DELETE и другими. Это делает протокол интуитивно понятным для разработчиков.

Доступный отладчик

HTTP API более прозрачны и их легче отлаживать с использованием инструментов, таких как браузерные расширения или утилиты наподобие cURL.

gRPC

Высокая производительность

gRPC использует язык описания данных Protocol Buffers и мультиплексирование, что делает его более эффективным в передаче данных.

Сильная типизация

Использование Protocol Buffers облегчает работу с данными, их сериализацию и десериализацию.

Генерация клиентского кода

Протокол автоматически генерирует клиентский код для различных языков программирования, что упрощает интеграцию с клиентами.

Поддержка HTTP 2.0

gRPC основан на HTTP 2.0, что обеспечивает высокую производительность и возможность мультиплексирования запросов.

gRPC может быть хорошим выбором для разработки микросервисов и распределенных систем. Он также полезен, когда в приоритете стоит производительность. Сильные стороны HTTP раскрываются, когда разработчики стремятся к универсальности и простоте.

Особенности разработки на базе HTTP

Современные REST API обычно основаны на модели клиент-серверного взаимодействия, где клиенты отправляют запросы, а серверы отвечают на них, используя протокол HTTP версии 1.1. Этот протокол существует уже давно и широко поддерживается множеством SDK и браузерами. Однако есть одна важная особенность: протокол HTTP 1.1 ориентирован в основном на транзакционное взаимодействие.

В качестве аналогии представим ситуацию, когда вам нужно задать другу несколько вопросов по телефону. 

Так бы выглядел звонок другу по логике транзакционного взаимодействия

Преимущества 

1. Доступность. Разработчики активно применяют протокол, по нему написано множество гайдов и статей. REST согласован с протоколом HTTP и методами HTTP-запросов, что делает его понятным для разработчиков.

2. Легкость внедрения. У HTTP относительно низкий порог входа, а для передачи данных используется популярный формат JSON. Многие языки программирования относительно быстро осуществляют процесс сериализации и десериализации JSON, что ускоряет внедрение. Можно использовать и другие форматы — XML или BSON, каждый из которых имеет свои преимущества и недостатки.

3. Гибкость. REST API предоставляет возможность настраивать API компании в соответствии с индивидуальными запросами. 

О чем стоит помнить

Принципы проектирования REST работают, когда их соблюдают. Если разработчики игнорируют стандарты, то создание документации превращается в большую проблему. В этом случае стоит обратить внимание на Postman. Совместно со спецификацией OpenAPI он позволяет генерировать документацию и образцы кода, задавая структуру, эндпойнты и результаты API. 

Другая проблема — ответы с большой полезной нагрузкой. Часто с ними сталкиваются разработчики, работающие со сложными по своей природе ресурсами. По этой причине возник интерес к GraphQL.

GraphQL предоставляет разработчикам гибкость и контроль над тем, какие ресурсы и атрибуты они хотят включить в ответ от сервера. В отличие от REST, где сервер определяет формат и содержание ответа, в GraphQL клиенты могут явно указать, какие данные им нужны. Это позволяет избежать лишней полезной нагрузки и уменьшить передачу данных по сравнению с REST API.

Если вы предпочитаете универсальность и простоту и ваш проект не требует высокой производительности, то HTTP остается хорошим выбором. 

Особенности разработки на базе gRPC

Для понимания логики gRPC лучше дать историческую справку. Протокол разработали в Google в 2016 году как высокопроизводительное решение для взаимодействия между микросервисами. Из этого следуют все преимущества и слабые стороны протокола.

Обратимся к аналогии со звонком другу. Она будет выглядеть примерно так:

Звонок другу по логике gRPC

В основе HTTP и gRPC схожи: разработчики определяют правила взаимодействия между клиентом и сервером. Они определяют, какие методы доступны, какие ресурсы можно использовать и какие параметры и данные можно передавать.

gRPC реализует четыре типа методов обслуживания для передачи данных:

1. Унарный (Unary). Позволяет клиенту отправить один запрос и получить один ответ от сервера. Подходит для ситуаций, когда клиенту нужно выполнить операцию и получить результат, например при аутентификации или получении деталей о каком-либо ресурсе.

2. Потоковая передача от сервера к клиенту (Server Streaming). Клиент отправляет один запрос, а сервер отвечает потоком данных, отправляя клиенту множество сообщений. Например, когда запрошена лента новостей и сервер отправляет новости по мере их появления.

3. Потоковая передача от клиента к серверу (Client Streaming). Клиент отправляет поток данных на сервер, а сервер отвечает одним сообщением. Полезно при передаче большого объема данных или логировании событий.

4. Двунаправленная потоковая передача (Bidirectional Streaming). Клиент и сервер отправляют потоки данных друг другу. Этот тип метода подходит, например, для чата или передачи видеопотока.

Типы запросов gRPC в Postman

Преимущества

1. Protocol Buffers — «легковесный» формат взаимодействия. Это позволяет экономить трафик. Формат данных может быть мгновенно преобразован в структуры данных, поддерживаемые независимыми языками программирования клиента и сервера. 

2. Скорость. Архитектор программного обеспечения Рувана Фернандо писал, что gRPC API в 7–10 раз быстрее REST API. Это происходит благодаря оптимизированной передаче данных и многим другим факторам, включая механизмы сжатия данных и возможность мультиплексирования запросов и ответов в рамках одного соединения.

3. Эффективное взаимодействие. gRPC позволяет клиенту выполнять «удаленные» (серверные) инструкции, как если бы сервер был частью локальной системы. Это достигается благодаря использованию Protocol Buffers для определения интерфейса и передачи данных в бинарном формате, что уменьшает необходимость в сериализации и десериализации данных и делает взаимодействие более эффективным.

По этой причине gRPC используют для клиентов с ограниченным уровнем энергопотребления, таких как мобильные устройства и устройства IoT (интернет вещей).

4. Возможность поиска. Серверы, реализующие gRPC, могут предоставлять клиентам список доступных запросов по запросу. Это называется отражением на стороне сервера и имеет значительную ценность при работе с gRPC API. Хотя это не полноценная замена документации, список поддерживаемых инструкций значительно упрощает внедрение API. 

О чем стоит помнить

Проектирование и создание gRPC API объективно сложнее по сравнению с REST API, особенно если разработчики не имеют опыта работы с Protocol Buffers и бинарными данными. Сообщения Protocol Buffers представляют собой бинарные данные, что делает их нечитаемыми для человека. Это может затруднить отладку и тестирование.

Настройка серверов и клиентов gRPC может потребовать дополнительных усилий, особенно при использовании продвинутых функций, таких как аутентификация и шифрование.

Протокол используется при разработке микросервисов и распределенных систем со значительным потенциалом для роста. gRPC лучше справляется большими потоками данных и ресурсоемкими задачами.

Сравнение HTTP и gRPC 

Выбор между HTTP и gRPC зависит от того, что важнее для вашего проекта: универсальность и простота (HTTP) или производительность и сильная типизация (gRPC). Если вам нужно высокопроизводительное API с сильной типизацией и вы готовы использовать генерацию кода, то gRPC может быть хорошим выбором. Однако если вам важна универсальность и простота, то HTTP может быть предпочтительнее.