Rpc api что это
Выбор Request-Response парадигмы API: REST, RPC или GraphQL?
Авторизуйтесь
Выбор 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.
Плюсы:
Минусы:
REST и RPC для HTTP API
Последнее время при разработке HTTP API в основном используют REST,а не XML-RPC, SOAP и JSON-RPC. REST во многом превосходит другие “базирующиеся на RPC” подходы, которые могут ввести в заблуждение, из-за своих различий.
В данной статье рассматриваются REST и RPC в контексте создания HTTP API-интерфейсов, потому что именно они наиболее часто используются.
REST расшифровывается как “representational state transfer” (передача состояния представления), как описывает Рой Филдинг в своей диссертации. К сожалению, те кто не видел эту диссертацию, имеют свое представление о том, что такое REST и это приводит к большому беспорядку и разногласиям. REST позволяет настроить отношения клиент-сервер, где на стороне сервера данные предоставляются в простых форматах, часто JSON и XML. Такое представление ресурсов или коллекции ресурсов, которые затем могут изменяться клиентом, с помощью действий прописанных в гипермедиа на сервере. Гипермедиа имеет основополагающее значение для REST, по существу это только концепция предоставления ссылок на другие ресурсы.
Гипермедиа накладывает такие ограничения:
Эти ограничения (плюс еще несколько), использованые в REST архитектуре, помогают API в течение десятилетий, не только годов.
Перед тем как REST стал популярным (после того, как компании, такие как Twitter и Facebook, начали использовать его для своих API-интерфейсов), большинство API, были построены с использованием XML-RPC или SOAP.
“RPC” означает “remote procedure call” (удаленный вызов процедуры), и это в общем так же как вызов функции в JavaScript, PHP, Python и так далее, принимая имя и аргументы метода. Так как XML не каждому по вкусу, RPC API может использовать протокол JSON-RPC.
Возьмем такой пример RPC вызова:
В JavaScript мы будем делать то же самое. Определим функцию, а затем вызовем её в другом месте:
Идея такая же. API строится путем определения публичных методов, затем эти методы вызываются с аргументами. RPC это просто набор функций, но в контексте HTTP API, что предполагает ввод метода в URL и аргументы в строку запроса или тело. SOAP может быть невероятно многословным как для доступа к аналогичным данным, так и к отчетности. Если вы будете искать “пример SOAP” на Google, вы найдете пример с Google, который демонстрирует метод, названный getAdUnitsByStatement, который выглядит следующим образом:
Это огромная нагрузка для того что б вернуть этот аргумент:
В JavaScript, что будет выглядеть следующим образом:
В формате JSON API, это может выглядеть следующим образом:
Даже если этот код гараздо меньше, мы по-прежнему должны иметь в виду различные методы для getAdUnitsByStatement и getAdUnitsBySomethingElse. REST выглядет лучше, когда вы рассматриваете эти примеры, так как это позволяет генерировать общие конечные точки в строке запроса (например, GET /ads?statement=
В этой статье мы не будем пытаться выделить что “лучшее”, а, скорее, поможем вам принять обоснованное решение о том, когда один из подходов может быть более хорош.
Для чего они?
RPC на основе API-интерфейсы прекрасно подходят для действий (процедуры или команды).
REST на основе API, прекрасно подходят для моделирования вашего домена, что делает CRUD (создание, чтение, обновление, удаление) доступными для всех ваших данных.
REST не только для CRUD, но все операции делаются главным образом на основе CRUD. REST будет использовать методы HTTP, такие как GET, POST, PUT, DELETE, OPTIONS и PATCH.
RPC, однако, использует только GET и POST, где GET используется для получения информации, а POST для всего остального. Вы часто могли наблюдать когда для RPC API используется это: POST /deleteFoo, с телом < “id”: 1 >, вместо REST, для которого бы прописывалось DELETE /foos/1.
Это не является важным отличием, это просто деталь реализации. Самая большая разница на мой взгляд, в том, как действия обрабатываются. В RPC вы просто имеете POST /doWhateverThingNow, и это довольно ясно. Но с REST со своими CRUD-подобными операциями вы можете почувствовать, что REST не подходит не для чего кроме CRUD обработки.
На самом деле это не совсем так. Инициирующие действия можно сделать с помощью любого подхода. Например, если вы хотите “Отправить сообщение” для пользователя, RPC будет следующим образом:
Но в REST, то же самое действие будет таким:
Представьте себе приложение Carpooling, который имеет “trips”. Эти trips должны иметь действия “start”, “finish” и “cancel”, или иначе пользователь никогда не будет знать, когда они начали или закончили.
В REST API, у вас уже есть GET /trips и POST /trips:
Этот кроссовер является признаком того, как сложно вносить действия в REST. Один из подходов заключается в использовании чего-то вроде поля состояния:
Как и в любой другой области, вы можете получать новое значение статуса в запросе PATCH и, исходя из этого, выполнять нужные действия:
В принципе, здесь, в ваших контроллерах, в коде lib или DDD-логике, вы можете проверить, было ли передано «статус» в запросе PATCH, и если да, вы можете попробовать перейти на него:
Когда этот код будет выполнен, он либо успешно выполнит переход, либо выполнит любую логику в блоке after_transition, либо выбросит ошибку.
Действиями success могут быть любые: отправка электронной почты, отключение push-уведомления, обращение к другой службе, чтобы начать просмотр местоположения GPS-устройства водителя, чтобы сообщить, где находится автомобиль – все, что вам нравится.
Альтернатива
Мы видели здесь два подхода корректирующих действия внутри REST API, не нарушая его REST-правил. В зависимости от типа приложения, для которого строится API, эти подходы могут быть менее логичными и более похожими на велосипеды. Можно начинать задаваться вопросом: почему я пытаюсь замять все эти действия в REST API? API RPC может быть отличной альтернативой, или это может быть новая услуга, дополняющая существующий REST API. Slack использует веб-API на основе RPC, потому что то, над чем он работает, просто не вписывается в REST. Представьте, что вы пытаетесь предоставить опции «kick», «ban» или «leave» для того, чтоб пользователи могли покинуть или удалиться из одного канала или из всей команды Slack, используя только REST:
DELETE кажется наиболее подходящим HTTP-методом для использования, но этот запрос настолько расплывчатый. Это может означать закрытие учетной записи пользователя полностью, что может сильно отличаться от запроса пользователя. Это явно не «kick» или «leave». Другим подходом может быть попытка PATCH:
Это было бы странно, потому что статус пользователя не был бы глобально изменен для всего, поэтому ему понадобилась бы дополнительная информация, переданная ему, чтобы указать канал:
В таком случае создается новое произвольное поле, которое передается, и это поле фактически не существует для пользователя. Отказавшись от такого подхода, мы могли бы попробовать работать с отношениями:
Это немного лучше, потому что мы больше не возимся с ресурсом global/users/jerkface, но он по-прежнему не имеет опции «kick», «ban» или «leave» и помещает это в тело или строку запроса.
Единственный другой подход, который приходит на ум, – создать коллекцию “kicks”, коллекцию “leaves” и коллекцию “bans”, с некоторыми запросами для POST/kicks, POST/bans и POST/leaves.
Slack Web API выглядит так:
Легко и просто! Мы просто отправляем аргументы для этой задачи, как и на любом языке программирования, который имеет функции.
Одно простое правило:
Что, если ни один из них не станет явным победителем? Какой подход вы выбираете?
Использование обоих – REST и RPC
Идея, что вам нужно выбрать один подход и иметь только один API, – это немного ложь. Приложение может очень легко иметь несколько API или дополнительных сервисов, которые не считаются «основным» API. С помощью любого API или сервиса, который предоставляет HTTP-запросы, у вас есть выбор между правилами REST или RPC, и, возможно, у вас будет один REST API и несколько RPC-сервисов. Например, на конференции кто-то задал этот вопрос:
У нас есть REST API для управления веб-хостинговой компанией. Мы можем создавать новые экземпляры серверов и назначать их пользователям, что хорошо работает, но как мы перезапускаем серверы и запускаем команды по партиям серверов через API по RESTful?
Нет никакого реального способа сделать это, что не является ужасным, кроме создания простой службы типа RPC, которая имеет метод POST / restartServer и метод POST / execServer, который может быть выполнен на серверах, построенных и поддерживаемых через сервер REST.
Итого
Знание различий между REST и RPC может быть невероятно полезным, когда вы планируете новый API, и это может реально помочь, когда вы работаете над функциями для существующих API. Лучше всего не смешивать стили в одном API, потому что это может смущать как потребителей вашего API, так и любых инструментов, которые ожидают один набор соглашений (например, REST), и которые падают, когда вместо этого он видит другой набор соглашений (RPC). Используйте REST, если это имеет смысл, или используйте RPC, если это более уместно. Или используйте оба и получите лучшее из обоих миров!
Сравнение архитектурных стилей API: SOAP vs REST vs GraphQL vs RPC
Feb 4 · 12 min read
Два отдельных приложения нуждаются в посреднике, чтобы общаться друг с другом. Поэтому разработчики часто строят мосты — программные интерфейсы приложений, они же API, — чтобы предоставить одной системе доступ к информации или функциональности из другой.
Чтобы способствовать быстрой и масштабной интеграции приложений, API реализуются с использованием протоколов и/или спецификаций, определяющих семантику и синтаксис передаваемых сообщений. Эти спецификации составляют архитектуру API.
Со временем появились различные архитектурные стили API. Каждый из них содержит собственные схемы стандартизации обмена данными. Наличие выбора вызывает бесконечные споры о том, какой архитектурный стиль лучше.
Сегодня многи е пользователи API называют REST “Rest in peace” (“Покойся с миром”) и болеют за успех GraphQL, в то время как десять лет назад ситуация была обратной: REST как победитель, пришедший на замену SOAP. Проблема с этими мнениями в том, что они однобоко поднимают на щит какую-то технологию вместо того, чтобы рассматривать ее фактические свойства и характеристики относительно конкретной ситуации.
В этой статье мы останемся объективными и обсудим четыре основных стиля API в порядке их появления, сравним их сильные и слабые стороны и выделим сценарии, для которых каждый из них подходит лучше всего.
Удаленный вызов процедуры (RPC): вызов функции в другой системе
Удаленный вызов процедуры ( Remote Procedure Call) — это спецификация, которая позволяет удаленно выполнять функцию в другом контексте. RPC расширяет понятие локального вызова процедуры, но помещает его в контекст HTTP API.
Проблематичность первоначального XML-RPC связана со сложностями в обеспечении типов данных для полезных нагрузок XML. Позже API RPC задействовал более конкретную спецификацию JSON-RPC, которая считается более простой альтернативой SOAP. gRPC — последняя версия RPC, разработанная компанией Google в 2015 году. Благодаря подключаемым поддержке балансировки нагрузки, трассировки, проверки работоспособности и аутентификации gRPC хорошо подходит для микросервисов.
Как работает RPC
Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер. Получив сообщение, сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Стаб сервера и стаб клиента берут на себя сериализацию и десериализацию параметров.
Преимущества RPC
Простота и понятность взаимодействий. RPC использует GET для получения информации и POST для всего остального. Механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
Легкость добавления функций. Получив новое требование для API, мы можем легко добавить другую конечную точку, выполняющую это требование: 1) написать новую функцию и перебросить ее на конечную точку, и 2) теперь клиент может попасть в эту конечную точку и получить информацию, соответствующую заданному требованию.
Высокая производительность. Легкие полезные нагрузки легко распределяются по сети, обеспечивая высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сетях рабочих станций. RPC способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации, когда различные сервисы каждый день обмениваются тоннами сообщений.
Недостатки RPC
Плотная связь с базовой системой. Уровень абстракции API способствует его повторному использованию. Чем теснее связанность с базовой системой, тем хуже API подходит для других систем. Тесная связь RPC с базовой системой не позволяет создать уровень абстракции между функциями в системе и внешним API. Отсюда вытекают вопросы относительно безопасности, поскольку детали реализации базовой системы довольно легко просачиваются в API. Плотная связанность RPC создает трудности для требований к масштабируемости и слабо связанных команды. Таким образом, клиент либо беспокоится о возможных побочных эффектах вызова определенной конечной точки, либо пытается выяснить, какую конечную точку следует вызвать, потому что не понимает, по какому принципу сервер именует функции.
Низкая обнаруживаемость. В RPC нет никакого способа интроспектировать API или отправить запрос и начать понимать, какую функцию вызывать на основе его запросов.
Взрыв функций. Новые функции создавать очень легко. Поэтому вместо того, чтобы редактировать существующие, мы создаем новые, в результате чего получаем огромный список перекрывающихся функций, которые трудно понять.
Примеры использования RPC
Шаблон RPC получил первое применение примерно в 80-х годах, но это само по себе не делает его устаревшим. Крупные компании, такие как Google, Facebook (Apache Thrift) и Twitch (Twirp), используют внутри себя высокопроизводительные вариации RPC для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами. Их массивные системы микросервисов требуют, чтобы внутренняя коммуникация была четкой и в то же время организованной в короткие сообщения.
API для команд. RPC — подходящий выбор для отправки команд в удаленную систему. Например, Slack API очень командно-ориентирован: зайти на канал, покинуть канал, отправить сообщение. Разработчики Slack API как раз и смоделировали его в стиле RPC, сделав его маленьким, компактным и простым в использовании.
Клиентские API для внутренних микросервисов. В случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количества метаданных, как это делает REST API. gRPC и Twirp очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности. gRPC, с HTTP2 под капотом, способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой тонн сообщений в день. Однако, если вы стремитесь не к высокой производительности сети, а к стабильному API-контакту между командами, публикующими очень отличающиеся друг от друга микросервисы, REST позаботится об этом лучше.
Протокол доступа к простым объектам (SOAP): предоставление данных в виде сервисов
SOAP — это высоко-стандартизированный протокол веб-коммуникаций, основанный на формате XML. Выпущенный Microsoft через год после XML-RPC, SOAP многое от него унаследовал. Когда на сцену вышел REST, они сначала применялись параллельно, но вскоре REST выиграл конкурс популярности.
Как работает SOAP
Формат XML тянет за собой много формальностей. В сочетании с массивной структурой сообщений он делает SOAP самым подробным стилем API.
SOAP-сообщение состоит из:
Логика SOAP API написана на языке описания веб-служб (WSDL). Этот язык описания API определяет конечные точки и описывает все процессы, которые могут быть выполнены. Это позволяет различным языкам программирования и IDE быстро налаживать коммуникацию.
SOAP поддерживает обмен сообщениями с отслеживанием состояния и без такового. В сценарии с отслеживанием состояния сервер хранит полученную информацию, которая может весить очень много. Но это оправдано для многосторонних операций и сложных транзакций.
Плюсы SOAP
Независимость от языка и платформы. Встроенная функциональность для создания веб-сервисов позволяет SOAP обрабатывать сообщения и делать ответы независимыми от языка и платформы.
Связанность с различными транспортными протоколами. SOAP гибок с точки зрения протоколов передачи и приспосабливается к более чем одному сценарию.
Встроенная обработка ошибок. Спецификация SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
Ряд расширений безопасности. Благодаря интеграции с протоколами WS-Security качество транзакций SOAP соответствует корпоративным стандартам. SOAP гарантирует конфиденциальность и целостность внутри транзакций, обеспечивая при этом шифрование на уровне сообщений.
Минусы SOAP
В наши дни многие разработчики содрогаются при мысли о необходимости интеграции SOAP API по нескольким причинам.
Только XML. SOAP-сообщения содержат много метаданных и поддерживают только подробные XML-структуры для запросов и ответов.
Тяжеловесность. Из-за большого размера XML-файлов SOAP-сервисы требуют большой пропускной способности.
Узкоспециализированные знания. Создание серверов SOAP API требует глубокого понимания всех задействованных протоколов и их строгих правил.
Утомительное обновление сообщений. Требуются дополнительные усилия для добавления или удаления свойств сообщения — жесткая схема SOAP замедляет принятие.
Сценарии применения SOAP
В настоящее время архитектура SOAP чаще всего применяется для интеграции внутри предприятий или с их доверенными партнерами.
Надежность передачи данных. Жесткая структура SOAP, а также возможности в плане безопасности и авторизации, делают его наиболее подходящим вариантом для обеспечения соответствия формальному программному контракту между API и клиентом при соблюдении юридического контракта между поставщиком API и потребителем API. Вот почему финансовые организации и другие корпоративные пользователи выбирают SOAP.
Передача состояния представления (REST): предоставление данных в качестве ресурсов
REST — самоописательный архитектурный стиль API, определяемый набором архитектурных ограничений и предназначенный для широкого внедрения многими потребителями API.
Наиболее распространенный сегодня стиль API был впервые описан в 2000 году Роем Филдингом в его докторской диссертации. REST делает доступными данные на стороне сервера, представляя их в простых форматах — чаще всего это JSON и XML.
Как работает REST
REST определен не так строго, как SOAP. RESTful-архитектура должна соответствовать шести архитектурным ограничениям:
На самом деле, некоторые сервисы соответствуют стандарту RESTful только в определенной степени. Они берут за основу стиль RPC, разбивают более крупные службы на ресурсы и эффективно используют инфраструктуру HTTP. Но ключевое здесь — гипермедиа, иначе HATEOAS, сокращенно от “Гипертекст как двигатель состояния приложения” (Hypertext As The Engine of Application State). По сути это означает, что с каждым ответом REST API предоставляет метаданные, связывающие всю информацию о применении API. Это то, что позволяет отделить клиента от сервера. В результате и поставщик API, и потребитель API могут развиваться независимо и это не затрудняет их коммуникацию.
“HATEOAS — ключевая особенность REST. Это действительно то, что делает REST самим собой. Поскольку большинство людей не используют HATEOAS, они пользуются HTTP RPC”, — такое радикальное мнение встретилось мне на Reddit. Действительно, HATEOAS — это самая зрелая версия REST. Однако этой цели трудно достичь. Для этого требуются гораздо более продвинутые и интеллектуальные клиенты API, чем те, которые обычно создаются и действуют в наши дни. Таким образом, даже действительно хорошие REST API сегодня не всегда соответствуют стандарту. Вот почему HATEOAS в основном служит ориентиром для долгосрочного развития дизайна RESTful API.
Между REST и RPC действительно может находиться серая зона, когда сервис реализует некоторые функции REST и некоторые RPC. REST основан на ресурсе (или существительном), а не на действии (или глаголе).
В REST все делается с помощью HTTP-методов, таких как GET, POST, PUT, DELETE, OPTIONS и, надеюсь, PATCH.
Сравнение архитектурных стилей API: SOAP vs REST vs GraphQL vs RPC
Два отдельных приложения нуждаются в посреднике, чтобы общаться друг с другом. Поэтому разработчики часто строят мосты — программные интерфейсы приложений, они же API, — чтобы предоставить одной системе доступ к информации или функциональности из другой.
Чтобы способствовать быстрой и масштабной интеграции приложений, API реализуются с использованием протоколов и/или спецификаций, определяющих семантику и синтаксис передаваемых сообщений. Эти спецификации составляют архитектуру API.
Со временем появились различные архитектурные стили API. Каждый из них содержит собственные схемы стандартизации обмена данными. Наличие выбора вызывает бесконечные споры о том, какой архитектурный стиль лучше.
Сегодня многие пользователи API называют REST “Rest in peace” (“Покойся с миром”) и болеют за успех GraphQL, в то время как десять лет назад ситуация была обратной: REST как победитель, пришедший на замену SOAP. Проблема с этими мнениями в том, что они однобоко поднимают на щит какую-то технологию вместо того, чтобы рассматривать ее фактические свойства и характеристики относительно конкретной ситуации.
В этой статье мы останемся объективными и обсудим четыре основных стиля API в порядке их появления, сравним их сильные и слабые стороны и выделим сценарии, для которых каждый из них подходит лучше всего.
Удаленный вызов процедуры (RPC): вызов функции в другой системе
Удаленный вызов процедуры (Remote Procedure Call) — это спецификация, которая позволяет удаленно выполнять функцию в другом контексте. RPC расширяет понятие локального вызова процедуры, но помещает его в контекст HTTP API.
Проблематичность первоначального XML-RPC связана со сложностями в обеспечении типов данных для полезных нагрузок XML. Позже API RPC задействовал более конкретную спецификацию JSON-RPC, которая считается более простой альтернативой SOAP. gRPC — последняя версия RPC, разработанная компанией Google в 2015 году. Благодаря подключаемым поддержке балансировки нагрузки, трассировки, проверки работоспособности и аутентификации gRPC хорошо подходит для микросервисов.
Как работает RPC
Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер. Получив сообщение, сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Стаб сервера и стаб клиента берут на себя сериализацию и десериализацию параметров.
Преимущества RPC
Простота и понятность взаимодействий. RPC использует GET для получения информации и POST для всего остального. Механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
Легкость добавления функций. Получив новое требование для API, мы можем легко добавить другую конечную точку, выполняющую это требование: 1) написать новую функцию и перебросить ее на конечную точку, и 2) теперь клиент может попасть в эту конечную точку и получить информацию, соответствующую заданному требованию.
Высокая производительность. Легкие полезные нагрузки легко распределяются по сети, обеспечивая высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сетях рабочих станций. RPC способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации, когда различные сервисы каждый день обмениваются тоннами сообщений.
Недостатки RPC
Плотная связь с базовой системой. Уровень абстракции API способствует его повторному использованию. Чем теснее связанность с базовой системой, тем хуже API подходит для других систем. Тесная связь RPC с базовой системой не позволяет создать уровень абстракции между функциями в системе и внешним API. Отсюда вытекают вопросы относительно безопасности, поскольку детали реализации базовой системы довольно легко просачиваются в API. Плотная связанность RPC создает трудности для требований к масштабируемости и слабо связанных команды. Таким образом, клиент либо беспокоится о возможных побочных эффектах вызова определенной конечной точки, либо пытается выяснить, какую конечную точку следует вызвать, потому что не понимает, по какому принципу сервер именует функции.
Низкая обнаруживаемость. В RPC нет никакого способа интроспектировать API или отправить запрос и начать понимать, какую функцию вызывать на основе его запросов.
Взрыв функций. Новые функции создавать очень легко. Поэтому вместо того, чтобы редактировать существующие, мы создаем новые, в результате чего получаем огромный список перекрывающихся функций, которые трудно понять.
Примеры использования RPC
Шаблон RPC получил первое применение примерно в 80-х годах, но это само по себе не делает его устаревшим. Крупные компании, такие как Google, Facebook (Apache Thrift) и Twitch (Twirp), используют внутри себя высокопроизводительные вариации RPC для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами. Их массивные системы микросервисов требуют, чтобы внутренняя коммуникация была четкой и в то же время организованной в короткие сообщения.
API для команд. RPC — подходящий выбор для отправки команд в удаленную систему. Например, Slack API очень командно-ориентирован: зайти на канал, покинуть канал, отправить сообщение. Разработчики Slack API как раз и смоделировали его в стиле RPC, сделав его маленьким, компактным и простым в использовании.
Клиентские API для внутренних микросервисов. В случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количества метаданных, как это делает REST API. gRPC и Twirp очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности. gRPC, с HTTP2 под капотом, способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой тонн сообщений в день. Однако, если вы стремитесь не к высокой производительности сети, а к стабильному API-контакту между командами, публикующими очень отличающиеся друг от друга микросервисы, REST позаботится об этом лучше.
Протокол доступа к простым объектам (SOAP): предоставление данных в виде сервисов
SOAP — это высоко-стандартизированный протокол веб-коммуникаций, основанный на формате XML. Выпущенный Microsoft через год после XML-RPC, SOAP многое от него унаследовал. Когда на сцену вышел REST, они сначала применялись параллельно, но вскоре REST выиграл конкурс популярности.
Как работает SOAP
Формат XML тянет за собой много формальностей. В сочетании с массивной структурой сообщений он делает SOAP самым подробным стилем API.
SOAP-сообщение состоит из:
Логика SOAP API написана на языке описания веб-служб (WSDL). Этот язык описания API определяет конечные точки и описывает все процессы, которые могут быть выполнены. Это позволяет различным языкам программирования и IDE быстро налаживать коммуникацию.
SOAP поддерживает обмен сообщениями с отслеживанием состояния и без такового. В сценарии с отслеживанием состояния сервер хранит полученную информацию, которая может весить очень много. Но это оправдано для многосторонних операций и сложных транзакций.
Плюсы SOAP
Независимость от языка и платформы. Встроенная функциональность для создания веб-сервисов позволяет SOAP обрабатывать сообщения и делать ответы независимыми от языка и платформы.
Связанность с различными транспортными протоколами. SOAP гибок с точки зрения протоколов передачи и приспосабливается к более чем одному сценарию.
Встроенная обработка ошибок. Спецификация SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
Ряд расширений безопасности. Благодаря интеграции с протоколами WS-Security качество транзакций SOAP соответствует корпоративным стандартам. SOAP гарантирует конфиденциальность и целостность внутри транзакций, обеспечивая при этом шифрование на уровне сообщений.
Минусы SOAP
В наши дни многие разработчики содрогаются при мысли о необходимости интеграции SOAP API по нескольким причинам.
Только XML. SOAP-сообщения содержат много метаданных и поддерживают только подробные XML-структуры для запросов и ответов.
Тяжеловесность. Из-за большого размера XML-файлов SOAP-сервисы требуют большой пропускной способности.
Узкоспециализированные знания. Создание серверов SOAP API требует глубокого понимания всех задействованных протоколов и их строгих правил.
Утомительное обновление сообщений. Требуются дополнительные усилия для добавления или удаления свойств сообщения — жесткая схема SOAP замедляет принятие.
Сценарии применения SOAP
В настоящее время архитектура SOAP чаще всего применяется для интеграции внутри предприятий или с их доверенными партнерами.
Надежность передачи данных. Жесткая структура SOAP, а также возможности в плане безопасности и авторизации, делают его наиболее подходящим вариантом для обеспечения соответствия формальному программному контракту между API и клиентом при соблюдении юридического контракта между поставщиком API и потребителем API. Вот почему финансовые организации и другие корпоративные пользователи выбирают SOAP.
Передача состояния представления (REST): предоставление данных в качестве ресурсов
REST — самоописательный архитектурный стиль API, определяемый набором архитектурных ограничений и предназначенный для широкого внедрения многими потребителями API.
Наиболее распространенный сегодня стиль API был впервые описан в 2000 году Роем Филдингом в его докторской диссертации. REST делает доступными данные на стороне сервера, представляя их в простых форматах — чаще всего это JSON и XML.
Как работает REST
REST определен не так строго, как SOAP. RESTful-архитектура должна соответствовать шести архитектурным ограничениям:
На самом деле, некоторые сервисы соответствуют стандарту RESTful только в определенной степени. Они берут за основу стиль RPC, разбивают более крупные службы на ресурсы и эффективно используют инфраструктуру HTTP. Но ключевое здесь — гипермедиа, иначе HATEOAS, сокращенно от “Гипертекст как двигатель состояния приложения” (Hypertext As The Engine of Application State). По сути это означает, что с каждым ответом REST API предоставляет метаданные, связывающие всю информацию о применении API. Это то, что позволяет отделить клиента от сервера. В результате и поставщик API, и потребитель API могут развиваться независимо и это не затрудняет их коммуникацию.
“HATEOAS — ключевая особенность REST. Это действительно то, что делает REST самим собой. Поскольку большинство людей не используют HATEOAS, они пользуются HTTP RPC”, — такое радикальное мнение встретилось мне на Reddit. Действительно, HATEOAS — это самая зрелая версия REST. Однако этой цели трудно достичь. Для этого требуются гораздо более продвинутые и интеллектуальные клиенты API, чем те, которые обычно создаются и действуют в наши дни. Таким образом, даже действительно хорошие REST API сегодня не всегда соответствуют стандарту. Вот почему HATEOAS в основном служит ориентиром для долгосрочного развития дизайна RESTful API.
Между REST и RPC действительно может находиться серая зона, когда сервис реализует некоторые функции REST и некоторые RPC. REST основан на ресурсе (или существительном), а не на действии (или глаголе).
В REST все делается с помощью HTTP-методов, таких как GET, POST, PUT, DELETE, OPTIONS и, надеюсь, PATCH.
Плюсы REST
Разделение клиента и сервера. По возможности разделяя клиент и сервер, REST обеспечивает лучшую абстракцию по сравнению с RPC. Система с уровнями абстракции способна инкапсулировать свои детали, чтобы лучше идентифицировать и поддерживать свои свойства. Поэтому REST API достаточно гибок, чтобы развиваться с течением времени и при этом оставаться стабильной системой.
Открытость. Все описывается связью между клиентом и сервером, так что для понимания, как взаимодействовать с REST API, не требуется никакая внешняя документация.
Дружественность к кэшу. REST — единственный стиль, который позволяет кэшировать данные на уровне HTTP благодаря повторному использованию множества HTTP-инструментов. В то же время, реализация кэширования в любом другом API потребует настройки дополнительного модуля кэширования.
Поддержка нескольких форматов. Возможность поддержки нескольких форматов хранения и обмена данными — одна из причин, по которым REST в настоящее время преобладает в сфере создания общедоступных API.
Минусы REST
Нет единой структуры REST. Нет точного правильного способа создания REST API. Как моделировать ресурсы и какие ресурсы моделировать, будет зависеть от каждого сценария. Это делает REST простым в теории, но трудным на практике.
Большие полезные нагрузки. REST возвращает много богатых метаданных, так что клиент может понять все необходимое о состоянии приложения только из его ответов. И эта болтливость не имеет большого значения для большой сетевой трубы с большой пропускной способностью. Но это не всегда так. Это стало ключевым движущим фактором для Facebook, придумавшего описание стиля GraphQL в 2012 году.
Проблемы чрезмерных или недостаточных данных. Ответы REST зачастую содержат либо слишком много данных, либо их недостаточное количество, и создают необходимость в дополнительном запросе.
Сценарии использования REST
API-интерфейсы управления. API, ориентированные на управление объектами в системе и предназначенные для многих потребителей, распространены шире всего. REST помогает таким API, обеспечивая сильную обнаруживаемость и хорошую документацию, и тем самым вписывается в эту объектную модель.
Простые приложения, управляемые ресурсами. REST — это валидный подход для подключения приложений, управляемых ресурсами, которые не нуждаются в гибкости запросов.
GraphQL: запрос только необходимых данных
Для того, чтобы вернуть что-то нужное, требуется многократно вызывать REST API. И вот, чтобы изменить правила игры, был изобретен GraphQL.
GraphQL — это синтаксис, который описывает, как сделать точный запрос данных. Реализация GraphQL стоит того, если задействована модель данных приложения с большим количеством сложных сущностей, ссылающихся друг на друга.
В наши дни экосистема GraphQL расширяется посредством библиотек и мощных инструментов, таких как Apollo, GraphiQL и GraphQL Explorer.
Как работает GraphQL
GraphQL начинается с построения схемы, которая представляет собой описание всех запросов, которые возможно сделать в API GraphQL, и всех типов данных, которые они возвращают. Строить схему сложно, поскольку она требует строгой типизации на языке определения схемы (Schema Definition Language, SDL).
Клиент, который располагает схемой перед отправкой запроса, может проверить свой запрос и убедиться, что сервер сможет ответить на него. Добравшись до бэкэнда, операция GraphQL интерпретируется по всей схеме и разрешается с помощью данных для фронтэнда. Отправив один массивный запрос на сервер, API возвращает ответ в формате JSON с точно теми данными, которые мы запросили.
В дополнение к CRUD-операциям RESTful GraphQL содержит также подписки, которые позволяют в режиме реального времени получать уведомления от сервера.
Плюсы GraphQL
Типизированная схема. GraphQL заранее публикует то, что он может осуществить, что улучшает обнаруживаемость. Указывая клиенту на API GraphQL, мы можем узнать, какие запросы доступны.
Хорошо подходит для графических данных. Данные, которые находятся в глубоких отношениях связанности, но не годятся для плоских данных.
Никаких версий. Лучшая практика управления версиями — это вообще не версионировать API. В то время как REST предлагает несколько версий API, GraphQL использует единую развивающуюся версию, которая обеспечивает непрерывный доступ к новым функциям и способствует более чистому и удобному в обслуживании серверному коду.
Подробные сообщения об ошибках. Подобно SOAP, GraphQL предоставляет подробную информацию о возникших ошибках. Сообщение об ошибке включает в себя все резольверы и ссылается на конкретную часть запроса, на которой лежит ответственность.
Гибкие разрешения. GraphQL позволяет выборочно раскрывать определенные функции, сохраняя при этом личную информацию. Между тем архитектура REST не раскрывает данные порциями: либо все, либо ничего.
Минусы GraphQL
Проблемы производительности. GraphQL выторговывает сложность в обмен на действенность. Слишком большое количество вложенных полей в одном запросе может привести к перегрузке системы. Таким образом, для сложных запросов лучшим вариантом остается REST.
Сложность кэширования. Поскольку GraphQL не переиспользует семантику кэширования HTTP, кэширование требует приложения дополнительных усилий.
Много самообразования перед разработкой. Когда у них недостаточно времени, чтобы разобраться в нишевых операциях GraphQL и SDL, многие проекты решают пойти по известному пути REST.
Сценарии использования GraphQL
Мобильный API. В этом случае важна производительность сети и оптимизация полезной нагрузки единичного сообщения. И GraphQL предлагает более эффективную загрузку данных для мобильных устройств.
Сложные системы и микросервисы. GraphQL способен скрыть сложность нескольких интегрированных систем, лежащих в основе его API. Агрегируя данные из нескольких мест, он объединяет их в одну глобальную схему. Это особенно актуально для устаревших инфраструктур или сторонних API, которые расширились со временем.
Какой шаблон API лучше всего подойдет для вас?
У каждого API-проекта свои требования и потребности. Обычно выбор архитектуры зависит от:
Понимая все компромиссы, на которые подталкивает каждый стиль архитектуры, архитекторы API могут выбрать из них наиболее подходящий конкретному проекту.
Благодаря своей сильной связанности RPC хорошо годится для внутренних микросервисов, но это не вариант для сильного внешнего API или API-сервиса.
SOAP — это хлопотно, но его обширный функционал в плане безопасности по-прежнему незаменим для биллинговых операций, систем бронирования и платежей.
REST обладает самой высокой абстракцией и лучшим моделированием API. Но он, как правило, тяжелее в плане нагрузки на сеть и многословнее — недостаток, если вы работаете на мобильных устройствах.
GraphQL — большой шаг вперед с точки зрения извлечения данных, но не у всех достаточно времени и возможностей, чтобы его осваивать.
В конце концов, имеет смысл попробовать несколько небольших сценариев с определенным архитектурным стилем и посмотреть, подходит ли он и решает ли ваши проблемы. Если это так, попробуйте расширить его применение и посмотреть, как всё работает на большем числе вариантов использования.