rpc api что это

REST? Возьмите тупой JSON-RPC

В последнее время на Хабре разгорелось много споров по поводу того, как правильно готовить REST API.

Вместо того, чтобы бушевать в комментариях, подумайте: а нужен ли вам REST вообще?
Что это — осознанный выбор или привычка?

Возможно, именно вашему проекту RPC-like API подойдет лучше?

Итак, что такое JSON-RPC 2.0?
Это простой stateless-протокол для создания API в стиле RPC (Remote Procedure Call).
Выглядит это обычно следующим образом.

У вас на сервере есть один единственный endpoint, который принимает запросы с телом вида:

И отдает ответы вида:

Если возникает ошибка — ответ об ошибке:

Бонусом поддерживаются batch-операции:

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

Также клиент может отправлять «нотификации» — запросы без поля «id», которые не требуют ответа от сервера:

Библиотеки для клиента и сервера есть, наверное, под все популярные языки.
Если нет — не беда. Протокол настолько простой, что написать свою реализацию займет пару часов.

Работа с RPC-клиентом, который мне первым попался на npmjs.com, выглядит так:

Профиты

Согласованность с бизнес-логикой проекта

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

Есть предметные области, где операций в API должно быть больше чем сущностей.
Навскидку — проекты с непростыми бизнес-процессами, gamedev, мессенджеры и подобные realtime-штуки.

Да даже взять контентный проект вроде Хабра…

Нажатие кнопки «↑» под постом — это не изменение ресурса, а вызов целой цепочки событий, вплоть до выдачи автору поста значков или инвайтов.

Здесь также стоит упомянуть CQRS, с которым RPC-шный API будет смотреться лучше.

Во-вторых, кодов ответа в HTTP всегда меньше, чем типов ошибок бизнес-логики, которые вы бы хотели возвращать на клиент.

Кто-то всегда возвращает 200-ку, кто-то ломает голову, пытаясь сопоставить ошибки с HTTP-кодами.

В JSON-RPC весь диапазон integer — ваш.

JSON-RPC — стандарт, а не набор рекомендаций

Очень простой стандарт.

Нет никаких best practices с форумов, есть стандарт.
Нет разногласий в команде, есть стандарт.

Конечно же, качественно реализованный REST API можно полностью задокументировать. Однако…

Знаете, что и где нужно передать в запросе к Github API, чтобы получить объект reactions вместе с issue?

Хорошо это или плохо? Решайте сами, гуглите сами. Стандарта нет.

Независимость от HTTP

В теории, принципы REST можно применять не только для API поверх HTTP.
На практике все по-другому.

JSON-RPC over HTTP безболезненно переносится на JSON-RPC over Websocket. Да хоть TCP.
Тело JSON-RPC запроса можно прямо в сыром виде бросить в очередь, чтобы обработать позже.

Больше нет проблем от размазывания бизнес-логики по транспортному уровню (HTTP).

JSON-RPC пригодится, если у вас есть:
— Batch-запросы
— Нотификации, которые можно обрабатывать асинхронно
— Вебсокеты

Не то, чтобы это все нельзя было сделать без JSON-RPC. Но с ним — чуть легче.

Подводные камни

Если вы собираетесь кешировать ответы вашего API на уровне HTTP — RPC может не подойти.
Обычно это бывает, если у вас публичное, преимущественно read-only API.
Что-то вроде получения прогноза погоды или курса валют.

Если ваше API более «динамичное» и предназначено для «внутреннего» использования — все ок.

Все запросы к JSON-RPC API в логах веб-сервера выглядят одинаково.
Решается логированием на уровне приложения.

Для JSON-RPC нет инструмента уровня swagger.io.
Подойдет apidocjs.com, но он гораздо скромнее.
Впрочем, документировать такой простой API можно хоть в markdown-файле.

«REST» — об архитектуре, а не глаголах HTTP — возразите вы. И будете правы.

В оригинальной диссертации Роя Филдинга не указано, какие именно глаголы, заголовки и коды HTTP нужно использовать.

Зато в ней есть волшебное слово, которое пригодится даже при проектировании RPC API. «Stateless».

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

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

Насколько stateless должен быть API, чтобы не причинять проблем? Для контраста вспомним по-настоящему statefull протокол — FTP.

Клиент: [открывает TCP-соединение]
Сервер: 220 ProFTPD 1.3.1 Server (ProFTPD)
Клиент: USER anonymous
Сервер: 331 Anonymous login ok, send complete email address as your password
Клиент: PASS user@example.com
Сервер: 230 Anonymous access granted, restrictions apply
Клиент: CWD posts/latest
Сервер: 250 CWD command successful
Клиент: RETR rest_api.txt
Сервер: 150 Opening ASCII mode data connection for rest_api.txt (4321 bytes)
Сервер: 226 Transfer complete
Клиент: QUIT
Сервер: 221 Goodbye.

Состояние сеанса хранится на сервере. FTP-сервер помнит, что клиент уже прошел аутентификацию в начале сеанса, и помнит, в каком каталоге сейчас «находится» этот клиент.

Такой API сложно разрабатывать, дебажить и масштабировать. Не делайте так.

В итоге

Возьмите JSON-RPC 2.0, если решитесь сделать RPC API поверх HTTP или веб-сокетов.
Можете, конечно, придумать свой велосипед, но зачем?

Возьмите GraphQL, если он правда вам нужен.

Возьмите gRPC или что-то подобное для коммуникации между (микро)сервисами, если ваш ЯП это поддерживает.

Возьмите REST, если нужен именно он. Теперь вы, по крайней мере, выберете его осознанно.

Источник

Выбор Request-Response парадигмы API: REST, RPC или GraphQL?

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

Чтобы сэкономить время, силы, а самое главное деньги, стоит посмотреть на best practices, которые применяются на текущий момент. Это поможет разработать API, который позволит вносить необходимые изменения в будущем. За прошедшие годы появилось несколько форматов API, рассмотрим самые популярные из них.

Request-Response APIs

Первую группу API, которую мы рассмотрим, можно выделить как Request-Response API. Основные отличия данной группы:

Самые популярные request-response API: REST, RPC и GraphQL.

Самый популярный подход на данный момент. Используется такими поставщиками API, как, например, Google, Twitter и GitHub.

Когда мы говорим про REST, мы говорим про ресурсы. Ресурс — это объект, который может быть идентифицирован, назван, адресован или обработан в сети. REST представляет данные как ресурсы и использует стандартные HTTP-методы для представления транзакций создания, чтения, обновления и удаления этих ресурсов, то есть стандартные CRUD операции. По сути, все бизнес-сущности, которыми оперирует сервис, могут быть определены как ресурсы.

Общие правила, которым следует RESTful API:

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

Для API, предоставляющего CRUD-операции.

Remote Procedure Call (RPC)

Удаленный вызов процедур (RPC) — это одна из простейших парадигм API, в которой клиент вызывает исполнение блока кода на сервере. В то время как REST рассматривает всё как ресурсы, RPC рассматривает действия. Клиенты обычно передают имя метода и аргументы серверу и получают обратно JSON или XML.

Для API, предоставляющего действия, которые сложно инкапсулировать в CRUD операциях.

GraphQL

GraphQL — это язык запросов для API, который в последнее время приобрел значительную популярность. Он был разработан внутри Facebook в 2012 году до публичного выпуска в 2015 году. GraphQL позволяет клиентам определять структуру требуемых данных. Сервер возвращает именно эту структуру

В отличие от REST и RPC API, GraphQL требует только один эндпоинт URL. Также вам не нужны разные HTTP-методы для описания операции. Вместо этого вы указываете в теле JSON выполняете ли вы запрос или мутацию. GraphQL поддерживает методы GET и POST.

Плюсы:

Минусы:

Источник

Правильный JSON API или JSON RPC

Наверняка многие в курсе.

JSON — Текстовый формат обмена данными JSON
API — Программный интерфейс приложения API

Ключевые слова здесь: интерфейс обмена данными.

A, что же тогда JSON-RPC?

JSON — мы уже в курсе.

RPC — удаленный вызов процедур RPC

Приходим к выводу, что JSON-RPC это: удаленный обмен данными.

Наверняка этот обмен данными будет происходить с неким интерфейсом, т.е. с API.

И в чем проблема?! Спросите Вы. А в том, что некоторые программисты разрабатывая JSON API, т.е интерфейс, забывают про JSON-RPC.И начинается очередное изобретение велосипеда. Frontend программист говорит: «я передам тебе такой то json», а Backend программист отвечает: «а я тебе верну такой то json». И все бы ничего, но было бы хорошо вспомнить о том, что умные люди уже давно разработали стандарты, вернее протоколы обмена данными. И не какие то сверх сложные, а очень даже простые: JSON-RPC

Вероятно многие, если не сказать, что почти все, знают и даже пользуются этими протоколами. Написана куча серверов и т.д. Но вот лично меня не все устроило в существующих протоколах. Они показались мне не достаточно гибкими и не во всем логичными. Как вы уже догадались решил я изобрести свой велосипед json-rpc-1.5

Главные отличия от существующих протоколов это:

Получив кучу отрицательных комментариев и минусов, решил еще раз проверить, может я действительно, что то не так делаю? Естественно, всё что я здесь пишу, это мое личное мнение и я никому ничего не навязываю. Приведу пару примеров:
1. Пример запроса JSON API Yandex директ:

У них же можно почитать и про токены: Авторизационные токены

2. Пример из Сбербанк API Оплата из мобильного приложения с использованием Apple Pay
JSON запрос приводить не буду, он большой, по ссылке можно посмотреть.
Важно, что JSON запрос содержит «paymentToken». Вот ссылка на требования к формированию токена от Apple

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

Источник

RPC, Messaging, REST: Терминология

Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.

Вступление

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

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

Терминология

Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.

Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.

RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.

В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.

Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.

Messaging

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

Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.

Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.

Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.

Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.

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

Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции

EntityAddress ReadEntityAddress(string param1, string param2)

выразится в таком виде:

Заключение

Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.

Источник

gRPC vs REST, что выбрать для нового сервера?

Так что же такое gRPC и в чем его отличие от, уже ставшего классическим, REST? Лучше ли gRPC? Может gRPC это снова хипстерская технология, которую все скоро забудут?

Не для кого ни секрет, что REST доминирует в современном мире API, особенно, когда речь идет о веб-приложениях и инфраструктурах, на основе микросервисов. Мало кто даже вспомнит, про то что микросервисы могут общаться по другому. Это наверное самый популярный ответ на собеседовании. Да если добавить еще feign клиента из Spring, то получается совсем красота и минимальные трудозатраты. Но для определенного набора сценариев использования, модель gRPC начала играть небольшую, но важную роль. Давайте попробуем разобраться, когда же нам стоит использовать REST, а когда gRPC.

Вот простая матрица, сравнивающая основы REST API и gRPC (картинка взята из интернета):

REST API и RPC API на примере микросервисов.

Что такое приложения на основе микросервисов?

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

REST API

REST описывает организацию клиент-сервер, в которой внутренние данные предоставляются клиентам через формат обмена сообщениями JSON или XML. По словам Роя Филдинга, API квалифицируется как «RESTful», если соответствует следующим ограничениям:

Единый интерфейс: API должен предоставлять потребителям API определенные ресурсы приложения.

Независимость клиент-сервера: клиент и сервер работают независимо. Клиент будет знать только те URI, которые указывают на ресурсы приложения. Обычно они публикуются в документации API.

Без сохранения состояния: сервер не сохраняет данные, относящиеся к запросу клиента. Клиент сохраняет эти «данные состояния» на своем конце (через кеш).

Кэшируемые: ресурсы приложения, предоставляемые API, должны быть кэшируемыми.

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

Код по запросу (COD): это единственное необязательное ограничение REST. Это позволяет клиенту получать исполняемый код в качестве ответа от сервера. Другими словами, именно сервер определяет, как будут выполняться конкретные действия.

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

API RPC

Как предшественник REST, RPC (удаленный вызов процедур) представляет собой программную архитектуру, восходящую к 1970-м годам. RPC позволяет вызывать функцию на удаленном сервере в определенном формате и получать ответ в том же формате. Не имеет значения, какой формат использует сервер, выполняющий запрос, и не имеет значения, локальный это сервер или удаленный. RPC позволяет вызывать функцию на сервере и получать результат в том же формате.

Основная концепция RPC API аналогична концепции REST API. RPC API определяет правила взаимодействия и методы, которые клиент может использовать для взаимодействия с ним. Клиенты отправляют вызовы, которые используют «аргументы» для вызова этих методов. Однако в случае RPC API метод находится в URL-адресе. Аргументы, вызывающие методы, находятся в строке запроса. Чтобы проиллюстрировать это, вот как запрос RPC API сравнивается с запросом REST API:

RPC: запрос RPC API может использовать POST / deleteSmth и иметь строку запроса, которая говорит

REST: запрос REST API записывает этот запрос как DELETE / smth / 777.

Погружение в API gRPC

Как вариант архитектуры RPC, gRPC был создан Google для ускорения передачи данных между микросервисами и другими системами, которым необходимо взаимодействовать друг с другом. По сравнению с REST API, gRPC API уникальны в следующих отношениях:

Протобуф (Protobuf) вместо JSON

Построен на HTTP 2 вместо HTTP 1.1

Создание собственного кода вместо использования сторонних инструментов, таких как Swagger

Передача сообщений в 7-10 раз быстрее

Более долгая имплементация и реализация, чем REST

Думаю, стоит детальнее разобрать каждое из этих различий между API REST и gRPC.

Protobuf вместо JSON / XML

И REST API, и RPC API отправляют и получают сообщения с использованием форматов обмена сообщениями JSON или XML. Они также могут использовать другие форматы, но наиболее распространены JSON и XML. Из них JSON стал самым популярным форматом, поскольку он гибкий, эффективный, платформенно-независимый и не зависит от языка. Он также основан на тексте и удобочитаем для человека, что упрощает работу операторам. Проблема в том, что для определенных случаев использования JSON недостаточно быстр или легковесен при передаче данных между системами.
В отличие от REST и RPC, gRPC преодолевает проблемы, связанные со скоростью и весом, и предлагает большую эффективность при передаче сообщений, используя формат обмена сообщениями Protobuf (буферы протокола). Вот несколько подробностей о Protobuf:

Независимость от платформы и языка, например как JSON

Сериализует и десериализует структурированные данные для передачи в двоичном формате.

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

Ускоряет передачу данных, удаляя множество обязанностей, которыми управляет JSON, поэтому он может сосредоточиться исключительно на сериализации и десериализации данных.

Передача данных происходит быстрее, потому что Protobuf уменьшает размер сообщений и служит легким форматом обмена сообщениями.

Построен на HTTP 2 вместо HTTP 1.1

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

В отличие от этого, gRPC использует HTTP 2 и пользуется преимуществами поддержки HTTP 2 как для взаимодействия с клиентом, так и для двунаправленной связи. Таким образом, gRPC может управлять «унарными» взаимодействиями, аналогичными HTTP 1.1 (когда клиент отправляет один запрос, а сервер отправляет один ответ). В то же время клиенты могут также открывать долговременные соединения, в которых каждый вызов RPC открывает новый поток HTTP 2, также известный как двунаправленная, «мультиплексируемая» или потоковая связь.

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

GRPC предоставляет три типа потоковой передачи:

На стороне сервера: клиент отправляет сообщение запроса на сервер. Сервер возвращает поток ответов клиенту. После завершения ответов сервер отправляет сообщение о состоянии (и в некоторых случаях конечные метаданные), что завершает процесс. После получения всех ответов клиент завершает свой процесс.

На стороне клиента: клиент отправляет поток сообщений запросов на сервер. Сервер возвращает один ответ клиенту. Он (обычно) отправляет ответ после получения всех запросов от клиента и сообщения о состоянии (и в некоторых случаях конечных метаданных).

Встроенная генерация кода вместо использования сторонних инструментов

Функции генерации кода встроены в gRPC через встроенный компилятор протоколов. При использовании REST API необходимо использовать сторонний инструмент, например Swagger, для автоматической генерации кода для вызовов API на разных языках.

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

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

Передача сообщений в 7-10 раз быстрее

Согласно широко цитируемым тестам, опубликованным Руваном Фернандо, соединения gRPC API значительно быстрее, чем соединения REST API. Фактически, он сообщил, что они в 7-10 раз быстрее:

GRPC примерно в 7 раз быстрее REST при получении данных и примерно в 10 раз быстрее, чем REST при отправке данных для этой конкретной полезной нагрузки. В основном это связано с плотной упаковкой буферов протокола и использованием HTTP / 2 в gRPC

Вот результаты, которые получил Руван:

Более долгая реализация и имплементация, чем REST

Несмотря на преимущества в скорости передачи сообщений, реализация gRPC API намного медленнее, чем реализация REST API. По словам Руана Фернандо, внедрение простой службы gRPC занимает около 45 минут. Реализация веб-API или REST API занимает всего около 10 минут.

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

Мне пришлось потратить примерно 45 минут на внедрение этой простой службы gRPC, из которых я потратил всего около 10 минут на создание WebAPI. В основном это связано с тем, что REST давно стал мейнстримом, и большинство основных фреймворков (например, ASP.NET Core MVC) имеют встроенную поддержку для быстрого развертывания таких сервисов (с помощью соглашений и шаблонов)

Когда лучше использовать REST или gRPC?

Давайте сравним, когда вам следует рассмотреть возможность использования REST API и gRPC API:

Когда использовать REST API

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

Когда использовать API gRPC

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

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

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

Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет вашей системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.

Сети с низким энергопотреблением и низкой пропускной способностью: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость для сетей с ограниченным диапазоном пропускания и маломощных сетей (особенно по сравнению с JSON). Интернет вещей может быть примером такой сети, в которой могут быть полезны API gRPC.

Подведем итог о REST и gRPC

Из-за различных преимуществ API-интерфейсов gRPC, которые мы рассмотрели до сих пор, некоторые разработчики рассматривают gRPC как «будущее». Однако эти разработчики могут забегать вперед. gRPC еще не получил широкого распространения, и еще предстоит увидеть, будут ли его преимущества стимулировать более широкое распространение в будущем.

Для сравнения, REST поддерживается повсеместно, и практически каждая инфраструктура на основе микросервисов полностью зависит от API-интерфейсов REST как связующего звена, объединяющего их. Если ваш вариант использования не требует реализации gRPC, рисковать принятием gRPC на этом зарождающемся этапе (до широкого распространения) нецелесообразно и не нужно.

Источник