Возможно, вы слышали такие слова, как REST, когда речь идет о разработке программного обеспечения. REST - это очень часто используемая архитектура API, и разработчики широко используют ее для проектирования программных API. Интерфейсы прикладного программирования жизненно важны для любого программного приложения, и REST является одной из многих архитектур, которые используются для API.
В настоящее время gRPC архитектура набирает популярность, и она также претендует на решение некоторых проблем, традиционно связанных с REST API . Но в чем их различия? И какой из них следует использовать для вашего приложения? Чтобы узнать ответ на эти вопросы, нам необходимо подробнее разобраться в том, что такое gRPC в сравнении с REST и в каких сценариях они работают лучше. Но прежде чем мы разберемся во всем этом, давайте посмотрим, что такое API и что они дают микросервисам.
Что такое API?
Программные приложения могут взаимодействовать и общаться друг с другом с помощью интерфейсов прикладного программирования - API, которые работают как технические посредники. API отвечает за отправку запроса пользователя в систему, который затем получает ответ от системы.
Представьте, что вы заказываете телефон через Интернет. Вы заходите на сайт, связанный с Интернетом, и он отправляет информацию о вашем запросе на сервер. Затем сервер получает информацию, анализирует ее и, предприняв необходимые шаги, отвечает нам с деталями, отображаемыми на экране. Это становится возможным благодаря API.
API описывает, как выполнять такие запросы клиентов, какие структуры данных использовать и стандарты, которых должны придерживаться клиенты. Он также описывает виды запросов, которые одна программа может посылать другой. Оба стиля архитектуры gRPC стили архитектуры vs REST широко используются для проектирования API.
API и микросервисы
Приложения могут иметь либо монолитную архитектуру, либо микросервисную. В монолитном приложении все функции и модули программного обеспечения содержатся в едином блоке или кодовой базе. Микросервисное приложение, напротив, состоит из множества небольших модулей, которые взаимодействуют друг с другом через интерфейсы, такие как протокол HTTP.
Основная проблема монолитного стиля заключается в том, что систему становится сложнее изменять, обновлять и расширять, поскольку инженеры добавляют новые функции и сервисы поверх уже существующего фундамента. Изменение одного аспекта приложения может оказать пагубное влияние на другие разделы. Код монолита постепенно становится настолько переплетенным и сложным для понимания после многократного масштабирования, обновления и изменения, что требуется полный редизайн системы.
Эта проблема решается с помощью микросервисов. Этот архитектурный дизайн разделяет монолит на составляющие его компоненты, каждый из которых затем запускается как отдельное приложение. Каждое из этих приложений называется микросервисом. Затем эти отдельные микросервисы соединяются с помощью API. Этот набор микросервисов, связанных API, объединяется в более крупную архитектурную конструкцию. API обеспечивают связь и взаимодействие между каждым компонентом, входящим в микросервисную архитектуру. Некоторые популярные подходы к созданию API - GraphQL, RPC, и REST.
Что такое RPC?
URL: RPC - Удаленный вызов процедур - это веб-архитектура, которая позволяет выполнить сервис на удаленном сервере с помощью заранее определенной формы и получить ответ с тем же форматом. Стиль сервера, выполняющего запрос, будь то локальный или удаленный сервер, не учитывается при проектировании. RPC дизайн.
Источник изображения itrelease.com/Author Junaid Rehman
Основная функция RPC API-запроса такая же, как и у API REST. В RPC API-запросы определяют принципы взаимодействия и методы, которые делают взаимодействие возможным. Позже пользователь вызывает эти функции, используя параметры. Строка запроса URL содержит параметры, используемые для вызова операций.
Для создания запросов API RPC система использует структуру клиент-сервер. RPC интерпретирует информацию, которую запрашивает пользователь, и передает ее на сервер. Пока внутренние коммуникации внутри серверов скрыты, сервер отвечает пользователю. Модель RPC модель также позволяет пользователю запрашивать услугу определенным образом. RPC Преимуществом модели является поддержка удаленных вызовов процедур как в децентрализованных, так и в локальных сценариях.
Что такое REST?
REST - Передача репрезентативного состояния - относится к архитектуре клиент-сервер, в которой пользователи имеют доступ к информации бэкенда через JSON или XML-коммуникации. API считается RESTful, если:
- Он имеет согласованный интерфейс и предоставляет клиентам API определенные ресурсы приложения.
- Сервер и клиент работают отдельно и независимо друг от друга. Клиенту известны только URI, указывающие на компоненты приложения.
- Он является безстатическим. Это означает, что только клиент сохраняет любую информацию о состоянии. Сервер не сохраняет никакой информации о состоянии при запросе клиента.
- Активы приложения, предоставляемые API, должны быть кэшируемыми.
- Имеет многоуровневую архитектуру.
Это применение современных архитектурных конструкций, которые зависят от нескольких ограничений для обеспечения передачи данных в гипермедийных сетях. RESTful web API нуждается в URL-кодированных аргументах для подключения к сервисам, использующим протоколы HTTP. REST API широко используются в современном веб-дизайне для создания безэталонных, расширяемых и надежных API.
Каждый компонент, объединяющий систему микросервисов, может быть показан пользователю или клиенту как актив, когда API REST становится общедоступным. Этот ресурс можно запросить с помощью команд HTTP GET, POST, PUT и DELETE .
Как работает REST?
REST использует протокол HTTP в качестве протокола связи по умолчанию при работе с сервисами, указанными в запросах API. Ресурс - это вещь, которая сравнима с объектом в объектно-ориентированном дизайне. Ресурс RESTful имеет действия и атрибуты, во многом схожие с объектом. В целом, реализации REST обычно уделяют меньше внимания действиям RESTful и больше концентрируются на атрибутах ресурса. RESTful решения - это решения, которые просто используют атрибуты для представления RESTful ресурса.
В RESTful API пользователь отправляет запрос на URL - Uniform Resource Locator, который вызывает ответ с полезной нагрузкой в формате JSON, XML или любом другом поддерживаемом формате данных. Эта полезная нагрузка представляет собой ресурс, который нужен пользователю. Обычные клиентские запросы включают
- метод HTTP, который определяет, что должно быть обработано на ресурсе
- путь к ресурсу
- Заголовок, содержащий данные о запросе
- полезная нагрузка в виде сообщения, специфичного для клиента.
В поле Accept заголовка пользователь указывает типы данных, которые он может принимать. Заголовок content-type, определяющий формат доставки сообщения, используемый в теле ответа, отправляется API-сервером вместе с полезной нагрузкой, которую он доставляет пользователю, сделавшему запрос. Код ответа, информирующий пользователя о статусе результата вызова API, также включается в тело ответа.
Что такое gRPC?
gRPC - Удаленный вызов процедур Google - это подтип конструкции RPC. gRPC это высокопроизводительная глобальная архитектура RPC с открытым исходным кодом, которая гарантирует гибкость и скорость для микросервисной архитектуры. Вызовы функций используются gRPC для обеспечения взаимодействия с клиентами в микросервисах, созданных с использованием различных языков кодирования.
Эта техника реализует RPC API-запросы с использованием стандарта HTTP 2.0, но ни сервер, ни программист API не знакомы с HTTP. В результате снижается сложность, поскольку нет причин беспокоиться о том, как принципы RPC будут переведены на язык HTTP.
Google Remote Procedure Call стремится ускорить передачу данных между микросервисами. Чтобы обеспечить возможность удаленного возврата и вызова, он основан на стратегии, которая идентифицирует сервис, устанавливает методологии и определяет соответствующие переменные.
Кроме того, для определения парадигмы API RPC используется IDL - язык описания интерфейсов, что упрощает определение удаленных функций. По умолчанию IDL использует Protocol Buffers для определения интерфейса сервиса и формата сообщений полезной нагрузки.
Как gRPC работает?
Протокол HTTP/2, потоковая передача и буферы протокола или protobufs используются gRPC API для передачи сообщений. Стандарт сериализации под названием protobuf позволяет автоматически создавать пользовательские библиотеки и упрощать построение микросервисов. В протофайлах разработчики API описывают операции и сообщения, которые передаются между серверами и клиентами.
Компилятор protoc загружает файлы и создает пользовательское и серверное программное обеспечение для взаимодействия с удаленными сервисами. По сравнению с форматами XML или JSON, сообщения, зашифрованные с помощью буферов протоколов, значительно меньше, что делает их обработку менее CPU-емкой.
Кроме того, использование HTTP/2, gRPC API привносят различные улучшения в разработку RPC. Протокол добавляет слой двоичного формата, который разбивает пакеты на более мелкие сообщения с двоичным обрамлением, делая их транспортабельными и небольшими. Выполнение многих вызовов внутри одного канала становится возможным благодаря поддержке HTTP/2 нескольких одновременных запросов с архитектурой двунаправленной связи.
Транспортный протокол HTTP/2 поддерживает несколько одновременных потоков, но gRPC API расширяют эту функциональность с помощью каналов. Каждый канал может вмещать несколько потоков, работающих одновременно через множество одновременных соединений. Каналы предлагают прямой метод подключения к серверу API по заданному адресу и порту. Через каналы также можно создать клиентский шлейф.
gRPC vs REST: сравнение
Google создал gRPC как вариант RPC, чтобы справиться с некоторыми ограничениями существующих стилей архитектуры API. Он решает некоторые проблемы, связанные с REST API, но gRPC API сталкиваются с определенными проблемами из-за того, что это более новая технология. Существует множество случаев использования, когда API REST может лучше подойти для вашего приложения. Вы сможете решить, какой из этих API может лучше работать с вашим программным обеспечением, если будете знать различия между ними.
HTTP 1.1 против HTTP 2
Подход "запрос-ответ", используемый в REST API, основан в основном на HTTP 1.1. Это означает, что модель должна обрабатывать каждый запрос отдельно, если микросервис получает много запросов от нескольких клиентов, что приводит к затягиванию работы всей системы. REST API могут быть разработаны на основе HTTP 2, но поскольку архитектура связи по-прежнему представляет собой запрос-ответ, они не могут полностью использовать преимущества HTTP 2, включая двунаправленную совместимость и потоковое взаимодействие.
gRPC API не сталкиваются с этой проблемой. Он придерживается модели соединения "клиент-ответ" и основан на HTTP 2. gRPC может принимать множество запросов от различных клиентов и обрабатывать эти запросы одновременно с помощью потоковой информации. Эти обстоятельства позволяют осуществлять двунаправленную связь с потоковым взаимодействием. Кроме того, gRPC поддерживает унарные взаимодействия, подобные тем, что были созданы в HTTP 1.1.
gRPC API могут управлять:
- Унарные взаимодействия
Если клиент делает один запрос, но в ответ получает только один ответ. - Серверный поток
Серверное потоковое взаимодействие известно, когда сервер отвечает на запрос клиента потоком сообщений. Сервер также посылает сообщение о состоянии, чтобы завершить процедуру после предоставления всех данных. - Клиент-поток
Это происходит, когда клиент передает последовательность сообщений, а сервер отвечает одним сообщением. - Двунаправленный поток
Это позволяет передавать данные в обоих направлениях, поскольку каналы сервера и клиента независимы друг от друга.
Поддержка браузеров
Поскольку большинство взаимодействий с веб-интерфейсами происходит в режиме онлайн, поддержка браузеров является ключевым фактором в споре о том. gRPC против REST. Поддержка браузера, вероятно, является одним из ключевых преимуществ REST API по сравнению с . gRPC. Все браузеры предлагают полную функциональность API REST и поддержку браузера. Функциональность gRPC в браузерах, однако, все еще относительно ограничена. К сожалению, для перехода между HTTP 1.1 и HTTP 2 требуется gRPC-web, а также прокси-слой. В результате, gRPC API, как правило, используются в основном для внутренних или частных систем, например, в API-приложениях, используемых для бэкенда информации и функциональности конкретных организаций.
В протоколе HTTP/2 используются мультиплексированные потоки. В результате многочисленные клиенты могут отправлять запросы параллельно, не открывая для каждого новый сеанс TCP. Кроме того, сервер может использовать существующую связь для доставки сообщений клиентам.
Модель репрезентативной передачи состояния имеет широкую поддержку в браузерах, поскольку в нее интегрирован HTTP 1.1. HTTP 1.1, который поддерживает REST, использует метод рукопожатия TCP для каждого запроса. REST В результате API часто имеют проблемы с задержками, поскольку квитирование занимает время.
Структура данных полезной нагрузки
Если мы смотрим на структуру данных полезной нагрузки при рассмотрении gRPC vs REST, gRPC API по своей конструкции сериализуют данные полезной нагрузки с помощью буферов протокола. Этот метод является более легким, так как делает сообщения меньше и позволяет получить сильно сжатую структуру. Буферы протокола имеют двоичный формат; поэтому для обмена данными он сериализует и десериализует информацию. Protobuf может автоматически переводить сложно написанные сообщения на языки программирования клиента и сервера.
RESTОднако для передачи и получения информации в основном используются формы JSON или XML. JSON является наиболее широко используемым форматом из-за его адаптивности и способности передавать динамические данные без соблюдения точной структуры, хотя она и не требуется. Еще одним важным преимуществом JSON является его человекочитаемость, с которой Protobuf пока не может сравниться.
JSON Однако JSON не так быстр и легок, когда речь идет о передаче данных. Это связано с требованием, что JSON должен быть сериализован и переведен на языки программирования, используемые как на сервере, так и на клиенте при использовании REST. Это дополнительный шаг в процессе передачи данных, который может снизить эффективность и увеличить вероятность ошибок.
Генерация кода
Инженеры должны использовать сторонние инструменты, такие как Postman, для генерации кода для запросов к API, так как, в отличие от gRPCAPI REST API не имеет встроенных средств генерации кода. В отличие от этого, gRPC предлагает встроенные средства генерации кода благодаря своему компилятору protoc, который поддерживает множество языков программирования. Генерация кода особенно полезна для микросервисов, которые объединяют множество сервисов, созданных на разных платформах и языках. В целом, встроенная генерация кода упрощает создание комплекта для разработки программного обеспечения - SDK.
REST API, с другой стороны, не предоставляет встроенных функций генерации кода. Вы должны использовать стороннюю программу для генерации кода для вызовов API на нескольких языках. Хотя это не так сложно, важно отметить, что gRPC не полагается на какие-либо другие сервисы для генерации кода.
Когда следует использовать API REST
При сравнении gRPC с REST, наиболее широко используемыми и популярными API для интеграции инфраструктур, построенных на микросервисах, являются API REST. REST API, вероятно, еще долго будут оставаться вариантом по умолчанию для подключения приложений, независимо от того, создаете ли вы внутреннюю сеть или открытую платформу, которая открывает свои активы для всего мира. REST API также идеально подходят для систем, требующих быстрой итерации и стандартов протокола HTTP.
REST API могут стать вашим первым выбором для разработки веб-сервисов, микросервисов и интерфейсов приложений, поскольку сторонние технологии повсеместно поддерживают их. В отличие от gRPCAPI имеют широкую поддержку в браузерах и не ограничиваются частными системами. Это может сделать REST API очень полезным во многих контекстах.
Кроме того, REST легче изучать, так как он имеет широкий спектр документации по API, доступной в Интернете. Такое упрощение процесса обучения очень важно, если вы ограничены во времени. Вы можете сэкономить много времени на исследования и обучение и сразу же приступить к реализации. RESTful API также легче интегрировать в приложения. Они также обеспечивают лучшую масштабируемость. Если вы хотите в скором времени расширить свое приложение, возможно, лучше использовать API REST. Отсутствие состояния и конфиденциальности может вызвать проблемы с репрезентативной передачей состояния в некоторых приложениях. Если в вашем приложении есть возможность оплаты, gRPC может оказаться лучшим вариантом.
Когда использовать gRPC API
В обоих gRPC vs REST, большинство сторонних инструментов все еще не предоставляют встроенную функциональность для gRPC соответствия. В результате, gRPC API в основном используются для создания внутренних систем или структур, недоступных для внешних пользователей. С учетом этой оговорки, следующие ситуации могут использовать gRPC API:
- Соединения микросервисов
gRPC API особенно полезны для связывания архитектур, состоящих из легких микросервисов, где эффективность доставки сообщений имеет решающее значение благодаря низкой задержке и высокой пропускной способности связи.
- Мультиязычные системы
gRPC Превосходно справляется с обработкой коммуникаций в полиглотском контексте благодаря возможности генерации собственного кода для широкого спектра языков программирования.
- Потоковая передача данных в реальном времени
Если необходима связь в реальном времени, ваша система может передавать и получать данные в реальном времени, не дожидаясь одностороннего взаимодействия клиент-ответ, благодаря возможности gRPC обрабатывать двунаправленный поток.
- Сети с низким энергопотреблением и низкой пропускной способностью
Такие сети могут выиграть от использования в gRPC сериализованных сессий Protobuf, поскольку они обеспечивают легковесную связь, повышенную эффективность и быстроту. Например, сеть, которая выиграет от использования gRPC API, является Интернет вещей.
Чем поможет AppMaster?
Программирование сильно изменилось за последние десятилетия, новые технологии и фреймворки облегчают задачи разработчиков. No-code generation выводит это на новый уровень. Людям не нужно проходить крутые кривые обучения, и они могут быстрее разрабатывать приложения с помощью таких платформ, как no-code платформы, такие как AppMaster.
AppMaster поможет вам создать исходный код с нуля в соответствии с конкретными потребностями вашего приложения. Созданный код будет принадлежать вам, и вы сможете изменять его в соответствии со своими потребностями. Вы можете создавать различные модули, необходимые вашему приложению, с помощью AppMaster. Это намного дешевле и занимает меньше времени, чем привлечение целой команды разработчиков.
Разработчики могут отправлять запросы между микросервисами бэкенд-архитектуры, используя протокол gRPC используя платформу генерации no-code от AppMaster. Мы добавим API как для gRPC разработку веб-сервисов, так и gRPC мобильных приложений в следующем году, чтобы увеличить gRPC поддержку.
Заключение
В прошлом передача репрезентативного состояния была основным подходом при разработке API. Но между gRPC с REST, gRPC API постепенно становятся все более популярными. Несмотря на различные особенности, которые его выделяют, некоторые проблемы, такие как отсутствие поддержки браузера и документации по API, затрудняют его повсеместное применение. Однако, с развитием технологий и ростом сообщества, мы можем надеяться, что gRPC преодолеет сегодняшние трудности.
Наконец, выбирая между REST или gRPCили даже любой другой методологией API, такой как GraphQL или SOAP, зависит от конкретных потребностей вашего проекта. Некоторые приложения могут нуждаться в преимуществах, которые gRPC в то время как другим может потребоваться базовая функциональность, которую обеспечивает REST. Вам необходимо оценить функции и сценарии использования вашего приложения, чтобы сделать выбор между этими двумя технологиями.
