Недавно я провел Почтальон прямой эфир»,Как мы это сделали: поддержка gRPC», с несколькими членами инженерной команды Postman. Во время чата было поднято много отличных вопросов об эффективности, как gRPC отличается от API на основе HTTP (например, ОТДЫХАТЬ а также ГрафQL), как они спроектированы и построены в Postman, как проводить тестирование и многое другое. Это вызвало у меня интерес к более глубокому техническому сравнению двух типов API и тому, почему вы можете выбрать один из них.


Разработка API на основе HTTP

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

Используя аналогию с желанием задать другу несколько вопросов по телефону, HTTP 1.1 означает, что мы звоним нашему другу, задаем вопрос, получаем ответ и завершаем разговор. Мы звоним им снова, задаем следующий вопрос, снова заканчиваем разговор и так далее, пока не получим всю необходимую информацию.

API-интерфейсы REST широко используются, и поскольку их принципы преподаются разработчикам, они хорошо понимаются в отрасли. Согласование REST с HTTP и его методами протокола делает понимание желаемого действия более понятным для разработчиков. Их легче принять другим разработчикам, потому что они имеют более «пологий» уровень обучения, обычно используя Форматы данных JSON для передачи данных. JSON стал очень желанным форматом. Многие языки программирования сериализовать и десериализовать JSON относительно быстро, что опять же приводит к более быстрой реализации. Также можно использовать другие форматы, такие как XML, BSON или пользовательские форматы данных, которые имеют свои преимущества и недостатки.

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

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

API-интерфейсы GraphQL, которые также обычно основаны на HTTP 1.1 и преимущественно используют метод POST, устраняют многие проблемы избыточной/недостаточной выборки, присущие API-интерфейсам REST, когда отправляются «слишком много» данных (которые клиент отбрасывает) или «слишком много». мало» данных (из-за чего клиент делает больше звонков). Решение GraphQL состояло в том, чтобы позволить клиенту сделать запрос по имени и сообщить серверу, какие поля данных он хотел бы получить в ответе. Основным недостатком здесь является то, что разработчикам необходимо знать структуру базы данных, чтобы знать, что можно получить, и взаимодействие по-прежнему в основном осуществляется в текстовых форматах, таких как JSON.


Разработка API на основе gRPC

Google разработала, а затем выпустила gRPC в 2016 году для повышения производительности связи между микросервисами. Это усовершенствованный дизайн RPC, который был создан в 1970-х годах. Разработано с HTTP 2.0он обычно использует буферы протоколов (Protobufs) для строго двоичного формата связи между клиентом и сервером.

Основные принципы создания RPC API очень похожи на создание RESTl API. Разработчики определяют правила взаимодействия между клиентом и сервером, например методы для вызова. Клиенты отправляют вызов, используя аргументы для вызова методов, но в отличие от API REST, которые используют методы HTTP, такие как GET и POST, для определения желаемого действия, API RPC определяют этот метод в самом URL-адресе, а параметры запроса определяют инструкцию для выполнения. .

gRPC реализует четыре вида сервисных методов для передачи данных, что обеспечивает гибкость их общего использования:

  • Унарный: клиент делает один запрос, а сервер отправляет один ответ, аналогично REST через HTTP 1.1.
  • Клиентская потоковая передача: клиент может отправить несколько запросов на сервер, последний из которых указывает на то, что потоковые данные завершены, и сервер отправляет обратно один ответ.
  • Серверная потоковая передача: клиент отправляет первоначальный запрос, предупреждая сервер о том, что он готов принять поток данных, и сервер отвечает множеством ответов, последний из которых указывает, что поток завершен.
  • Двунаправленная потоковая передача: после первоначального унарного соединения между клиентом и сервером и клиент, и сервер могут отправлять потоки информации.

Типы запросов Postman gRPC с перечислением режимов Unary, Client-Streaming, Server-Streaming и Bidirectional Streaming.
Типы запросов Postman gRPC с перечислением режимов Unary, Client-Streaming, Server-Streaming и Bidirectional Streaming.

Буферы протоколов обеспечивают типобезопасный интерфейс и считаются «облегченным» форматом связи. Этот формат сильно сжат и позволяет немедленно преобразовывать в структуры данных, поддерживаемые независимыми языками программирования клиента и сервера. (Конечно, JSON и текстовые форматы также могут быть сжаты многими клиентскими и серверными системами, поддерживающими алгоритмы сжатия, такие как gzip перед транспортировкой.)

Основным преимуществом HTTP 2.0 и использования протокольных буферов является скорость. Руван Фернандо определил, что API-интерфейсы gRPC как правило, в семь-десять раз более производительный, чем REST API.. Важно подчеркнуть, что увеличение скорости связано не только с gRPC, но и с базовым сетевым уровнем и передачей данных. Используя нашу прежнюю аналогию с телефоном, чтобы задать другу несколько вопросов, HTTP 2.0 позволил бы нам позвонить нашему другу один раз, передать список вопросов, получить список ответов, а затем завершить вызов, что привело бы к меньшему общему трафику для восстановления соединения. связь между каждым вопросом.

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

Еще одним преимуществом gRPC является его «обнаруживаемость». В качестве дополнительного расширения серверы gRPC могут передавать список запросов клиентам, которые его запрашивают. Этот «отражение сервера” имеет огромное значение при работе с API gRPC. Хотя это и не является полной заменой документации, это упрощает внедрение API, когда разработчики могут получить список поддерживаемых инструкций. Кроме того, генерация кода — это функция, встроенная в gRPC благодаря компилятор протокола.

Основным недостатком gRPC является внедрение, и это внедрение связано со сложностью проектирования и создания API gRPC. gRPC, как правило, сложнее настроить и отладить, поскольку сообщения буфера протокола являются двоичными по своей природе и неудобны для чтения человеком. В то время как библиотеки RESTful и типы связи, такие как JSON, изначально поддерживаются в браузерах, для gRPC требуются сторонние библиотеки, такие как gRPC-web, а также прокси-уровень для выполнения преобразований между HTTP 1.1 и HTTP 2.0.

Поддержка сторонних инструментов и библиотек все еще является относительно новой для поддержки gRPC, и это может привести к тому, что команды будут создавать более внутренние API-интерфейсы на основе gRPC, чем внешние API-интерфейсы, ориентированные на клиентов. В результате Почтальон Общедоступная сеть API показывает только несколько API-интерфейсов gRPC, таких как Wechaty а также НОВА Безопасность. Вы можете увидеть некоторые примеры в рабочей области которые собрала наша команда DevRel.


Параллельное сравнение HTTP и gRPC для создания API

Как производитель API, у вас есть большой выбор. API-интерфейсы REST API от Postman хорошо известны благодаря подключению приложений и микросервисов в Интернете. REST соответствует стандартам HTTP и предлагает универсальную поддержку, а также упрощает разработку для многих команд. Несмотря на то, что его передача данных, как правило, больше, а его зависимость от HTTP 1.1 генерирует больше передачи данных для установления соединений между запросами, его передача данных легко просматривается и читается разработчиками в целях разработки и отладки программного обеспечения.

Архитектурный стиль gRPC — отличный выбор для работы с многоязычными приложениями и микросервисами. Его способность передавать контент в двух направлениях делает его эффективным выбором для систем, требующих более высоких коммуникационных нагрузок, чем одиночные циклы запроса/ответа. Его двоичный формат данных намного эффективнее, чем передача текста RESTful, а использование HTTP 2.0 снижает потребность в восстановлении соединений с серверами.

Обзор HTTP и gRPC
Краткий обзор HTTP и gRPC

Посмотрите примеры в нашем Общедоступная рабочая область API gRPC, и поищите в Postman Public API Network другие — мы обязательно будем выделять их все больше и больше в будущем! Мы также приветствуем ваши отзывы и вклад, поэтому, если вы найдете отличный общедоступный API gRPC, отправьте запрос на включение в нашу рабочую область.

Технический обзор Джойс Лин.

Пост Как выбрать HTTP или gRPC для вашего следующего API появился первым на Блог почтальона.