Разработка BI инструмента. Часть 2. Сравнение и выбор архитектуры API

В предыдущей статье была намечена базовая модель для будущего проекта. Однако осталась пара “черных ящиков”, которые так и не были описаны. Сейчас хотелось бы глубже затронуть тему API и оценить две популярные архитектуры: gRPC и REST API.

Варианты API

Так как на данный момент существует немалое количество программных интерфейсов и описать каждый, а потом и сравнить довольно накладно, то я решил остановиться на двух ,пожалуй, самых распространенных и проверенных временем: gRPC и REST.

SOAP и GRAPHQL

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

SOAP был исключен из списка по причине тесной привязки к XML и основным преимуществом которого является обширный функционал безопасности и больше подходит для передачи платежных и биллинговых транзакций. Да и сам процесс разработки интерфейса трудоемок.

GRAPHQL показался насколько интересным настолько и сложным в освоении вариантом. И так как архитектура довольно инновационная, поиск ответов на возникающие с ней вопросы может стать камнем преткновения в будущем. И опять же трудоемкий процесс освоения.

Итак, когда отборочный тур был пройден, можно сфокусироваться на финалистах.

gRPC

Несмотря на то, что эта конкретная архитектура разработана относительно недавно компанией Google, в отличие от ранее описанной GRAPHQL, её корни уходят 80-е года, когда получил свое первое применение его предок RPC(Remote Procedure Call). В 2016 же корпорация добра доработала и выпустила новую версию старой проверенной архитектуры.

Особенности

Отличительной чертой данной технологии как формы взаимодействия клиент-сервер является использование вызовов функций, а не привычный HTTP-вызов. Для этого используется IDL (Interface Description Language), язык взаимодействия с вызываемыми функциями и типами данных. Также gRPC вместе с IDL использует формат обмена сообщениями Protobuf (буферы протокола), который представляет собой высокоэффективный формат обмена сообщениями с высокой степенью упаковки для сериализации структурированных данных.

Принцип работы

Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер. Получив сообщение, сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Стаб сервера и стаб клиента берут на себя сериализацию и десериализацию параметров.

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

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

Protobuf

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

HTTP/2

Долгое время HTTP/1.1 не терял своей актуальности.

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

И это дало следующие возможности:

• Сжатие заголовков (HPack) - решает проблему когда HTTP заголовки занимают больше места чем полезная информация.

• Мультиплексирование запроса и ответа - позволяет получать полезные данные из нескольких запросов с одним и тем же заголовком, таким образом идентифицируя его как один запрос.

• Потоковая передача - стала доступна благодаря мультиплексированию.

Поэтому HTTP/2 - это одна из главных причин, почему gRPC может работать так хорошо. 

Метаданные

Метаданные - это тип данных "ключ-значение", которые могут быть установлены на стороне клиента или сервера и использоваться вместо обычных заголовков HTTP-запроса. Header могут быть назначены на стороне клиента, в то время как серверы могут назначать Header и Trailers при условии, что они оба находятся в форме метаданных.

Перехватчики

Библиотеки gRPC обычно поддерживают перехватчики и позволяют легко реализовать. Перехватчики обычно используются для:

• Изменяет запрос / ответ перед передачей. Его можно использовать для предоставления обязательной информации перед отправкой на клиент / сервер.

• Позволяют вам управлять каждым вызовом функции, например, добавлять дополнительные записи для отслеживания времени отклика.

Балансировка нагрузки

Балансировщик предоставляет возможность распределения клиентских запросов по разным серверам. В отличие от балансировки нагрузки на уровне HTTP сервера по типу nginx, gRPC поддерживает метод балансировки нагрузки клиентом.

Отмена вызова

Клиенты gRPC могут отменить вызов gRPC, когда ему больше не нужен ответ. Однако откат на стороне сервера невозможен. Эта функция особенно полезна для потоковой передачи на стороне сервера, когда могут поступать несколько запросов к серверу. Библиотека gRPC оснащена шаблоном метода наблюдателя, чтобы знать, отменен ли запрос, и позволяет ему отменить сразу несколько соответствующих запросов.

REST

Архитектурный стиль API определяется набором архитектурных ограничений и предназначен для широкого внедрения многими потребителями API. Это программный интерфейс делает доступными данные на стороне сервера, представляя их в простых форматах  —  чаще всего это JSON и XML.

Особенности

Пожалуй главной особенностью REST стоит считать архитектурное ограничение HATEOAS (Hypermedia As The Engine Of Application State) за счет которого с каждым ответом от сервера предоставляются метаданные, связывающие всю информацию о применении API.

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

Принцип работы

REST API использует запросы HTTP для выполнения стандартных CRUD-функций базы данных. Например, REST API может использовать запрос GET для получения записи, запрос POST для создания записи, запрос PUT для обновления записи и запрос DELETE для удаления записи. В вызовах API поддерживаются все методы HTTP. 

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

В отличие от RPC, основным преимуществом REST считается лучшая абстракция позволяющая четко разграничить клиент и сервер, а также инкапсулировать свои детали.

Масштабируемость и гибкость

Так как архитектура REST разделяет клиент и сервер, ее легко расширять, что позволяет масштабировать приложение без особых проблем. Кроме того, эта архитектура весьма гибкая и дает возможность обрабатывать различные типы запросов и форматы данных.

Кэширование

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

Ресурс-ориентированность

Каждая единица информации (ресурс) однозначно определяется URL — это значит, что URL по сути является первичным ключом для единицы данных. Причем совершенно не имеет значения, в каком формате находятся данные по адресу — это может быть и HTML, и jpeg, и документ Microsoft Word.

Вывод

gRPC предоставляет множество преимуществ. В отличие от REST, он может максимально использовать возможности HTTP 2, благодаря технологии мультиплексирования и сжатию заголовков. Кроме того, он предлагает преимущества в производительности благодаря структуре сообщений Protobuf, и давайте не будем забывать о встроенных функциях генерации кода, которые обеспечивают многоязычную среду. Эти причины делают gRPC многообещающим архитектурным стилем API.

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