Привет Это канал Listen it и сегодня мы слушаем статью сравнение архитектурных стилей API со rest graphql и rpc от автор Рудольф коршун который написал Стась на сайте medium.com это перевод англоязычной статьи которая тоже была на медиуме выпущена Так что ссылочки на обе версии на англоязычную и на русскоязычную будут конечно в описании к этому видео перед началом правда вставлю маленькую ремарок от себя в названии говорится про архитектурные стили Хотя соб на самом деле это протокол а GR ql - это язык запросов и серверная среда Ну это уже нюансы Я думаю что автор статьи в названии Просто
обобщил этот момент сегодня будем обсуждать разные методы построения интеграции между системами и как лучше выбрать подходящую технологию для вашего API думаю объяснять что такое API нашим зрителям не нужно но если ты вдруг новичок в it и хочешь узнать основы Или вдруг хочется разобраться в том что такое websocket Mac адре или docker то Тебе явно понравится Youtube канал marian Academy там рассказывают о сло технологиях простыми словами так что даже новичку будет всё понятно А ещё у ребят есть собственная it Академия с курсами на популярные темы как для новичков так и уже для опытных специалистов от SQL
до кибербезопасности мрин дают несколько бесплатных уроков по-любому из курсов чтобы можно было попробовать и понять Нравится ли тебе или нет А некоторые курсы так вообще бесплатные например по git github и созданию Telegram ботов на питоне ко всем курсам в подарок идёт бесплатный карьерный интенсив где ты узнаешь про то как создавать сильные резюме и проходить собеседование Ну и цены в maran Academy кстати одни из самых доступных на рынке а оплатить все курсы можно при желании хоть долями разделив платёж на 4 ише частей чтобы платить по чуть-чуть без каких-то переплат Так что если интересно переходи по ссылочки
в описании и пробуй пару бесплатных уроков от maran Academy Итак два отдельных приложения нуждаются в посреднике чтобы общаться друг с другом поэтому разработчики часто строят мосты программные интерфейсы приложений а ниже API Application programing Interface чтобы представить одно системе доступ к информации или функциональности из другой А чтобы способствовать быстрой и масштабной интеграции приложений API реализуется с использованием протоколов и спецификации которые определяют семантику и синтаксис передаваемых сообщений эти спецификации и составляют архитектуру API и со временем появились различные архитектурные стили протокола API каждый из них содержит собственные схемы стандартизации обмена данными и разные подходы а наличие выбора вызывает
бесконечные споры о том какой же архитектурный стиль или протокол или подход лучше сегодня многие пользователи API называют иронично rest rest in Peace покойся с миром и болеют за успех Граф куэ В то время как 10 лет назад ситуация была обратной рест как победитель пришедший на замену соп кстати и про СТ и про Граф Куль у нас были отдельные статьи и даже было видео про различия рест и соп ссылочки в описании оставлю Советую послушать Но проблема с этими мнениями в том что они однобоко поднимают на щит какую-то технологию вместо того чтобы рассматривать её фактические свойства и
характеристики относительно конкретной ситуации в этой статье Мы постараемся остаться объективными и обсудим четыре основных стиля API в порядке их появления сравним их сильные и слабые стороны и выделим сценарии для которых каждый из них подходит лучше всего начнём с rpc удалённый вызов процедур вызов функций в другой системе удалённый вызов процедур Remote procedure Call - это спецификация которая позволяет удалённо выполнять функцию в другом контексте rpc расширяет понятие локального вызова процедуры но помещает его в контекст http API проблематичность первоначального xml rpc связаны со сложностями в обеспечении типов данных для полезных нагрузок xml позже apir rpc задействовал более конкретную
спецификацию json rpc которая считается более простой альтернативой soop grpc - Это последняя версия rpc которая разработана Компани Google в 2015 году благодаря тому что можно подключать поддержку балансировки нагрузки трассировку проверку работоспособности и аутентификацию jpc Хорошо подходит для микросервисов подробнее про rpc и jpc мы опять же разговаривали В отдельной статье ссылочку в описанию ищи как же работает rpc клиент вызывает удалённую процедуру сериализовать параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер получив сообщение сервер дес реализует его содержимое выполняет запрошенную операцию и отправляет результат обратно клиенту стап сервера и стап клиента берут на себя
сериализации и десериализации параметров на экране можете посмотреть механизм удалённого вызова процедур Какие же есть преимущество у rpc Первое - это простота и понятность взаимодействий rpc использует Get для получения информации и пост для всего остального механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа второй плюс - это лёгкость добавления функций получив новые требование для API мы можем легко добавить другую конечную точку выполняющую это требование то есть пишем новую функцию и перебрасывая её на конечную точку и теперь клиент может попасть в эту конечную точку и получить информацию которая соответствует заданному требованию Ну
и третий плюс - это высокая производительность лёгкие полезные нагрузки легко распределяются по сети обеспечивая высокую производительность что довольно важно для общих серверов и параллельных вычислений которые выполняются в сетях рабочих станций rpc способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации когда различные се висы каждый день обмениваются тоннами сообщений Но плюсы плюсами есть у rpc и недостатки и первый недостаток - это плотная связь с базовой системой уровень абстракции API способствует его повторному использованию чем теснее связанность с базовой системой тем хуже API подходит для других систем тесная связь rpc с базовой системой не позволяет создать
уровень абстракции между функциями в системе и внешним API отсюда вытекают вопросы относительно безопасности потому что детали реализации базовой системы довольно легко просачиваются в API плотная связанность rpc создаёт трудности для требований к масштабируемости и слабо связанных команд таким образом клиент либо беспокоится о возможных побочных эффектах вызова определённой конечной точки либо пытается выяснить какую конечную точку следует вызвать потому что не понимает По какому принципу сервер именует функции второй недостаток - это низкая обнаруживаемые в rpc нет никакого способа интерспектин на основе его запросов Ну и третье взрыв функций новые функции как мы уже сказали создавать очень легко и
Поэтому вместо того чтобы редактировать существующие Мы обычно создаём новые и в результате чего получаем огромный список перекрывающихся функций которые трудно понять А теперь давайте посмотрим какие есть примеры использования rpc шаблон rpc получил первое применение примерно в Восьмидесятых годах Но это само по себе не делают его устаревшим крупные компании такие как Google Facebook и Twitch используют внутри себя высокопроизводительной вариации rpc для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами их массивная система микросервисов требует чтобы внутренняя коммуникация была чёткой и в то же время организованной в короткие сообщения rpc можно использовать как API для команд rpc -
это подходящий выбор для отправки команд в удалённую систему например slack API очень командно ориентирован зайти на канал покинуть канал Отправить сообщение разработчики SL API как как раз и смоделировали его в стиле rpc сделав его маленьким компактным и простым в использовании второе применение - это клиентский API для внутренних микросервисов в случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количество метаданных как это делает rest API grpc и TB фреймворк основанный на rpc который разработал Twitch очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности jpc http2 под
капотом способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой гигантского количества сообщений в день Однако если вы стремитесь не к высокой производительности сети а к стабильному API контакту между командами публикую очень отличающиеся друг от друга микросервисы rest позаботится об этом лучше Ну и как вы поняли учитывая что Twitch сам базируется свой фреймворк на rpc он Хорошо подходит для стриминга jpc например предоставляет встрой поддержку для стриминговых запросов и ответов что позволяет обмениваться данными между клиентом и сервером в реальном времени подходящим образом для стриминговых сервисов Ну что rpc обсудили вроде бы
вкратце Если хотите подробнее то прыгайте по ссылочки в описании отдельно мы про rpc grpc уже говорили а мы переходим к со протокол доступа к простым объектам предоставление данных в виде сервисов со - это высоко стандартизированный протокол вебком который основан на формате xml Microsoft выпустил его через год после xmlrpc и soop много от него унаследовал Когда уже на сцену вышел СТ они сначала применялись параллельно Но вскоре rest выиграл конкурс популярности Хотя и сейчас soop довольно часто встречается в компаниях как же работает soop формат xml тянет за собой много формальностей в сочетании с массивной структурой сообщений он
делает soop самым подробным стилем API соб сообщения состоит из тега конверта envelop которым начинается и заканчивается каждое сообщение тело которое содержит запрос или ответ заголовка Если сообщение должно определять какие-либо особенности или дополнительные условия и сообщение об ошибке информирующей о любых ошибках которые могут возникнуть в процессе обработки запроса вот на экране Посмотрите пример со сообщения логика so API написана на языке описания веб служб wsdl или как его называют у нас в sdl этот язык описания API определяет конечные точки и описывает все проце которые могут быть выполнены это позволяет различным языкам программирования и IDE быстро налаживать коммуникацию
со поддерживает обмен сообщениями с отслеживанием состояния и без него в сценарии с отслеживанием состояния сервер хранит полученную информацию которая может весить очень много но это оправдано для многосторонних операций и сложных транзакций Какие же есть плюсы у со Первое - это независимость от языка и платформы встроенная функциональность для создания веб-сервиса позволяет со обрабатывать сообщения и делать ответ независимыми от языка и платформы второе - это связанность с различными транспортными протоколами со гибок с точки зрения протоколов передачи и приспосабливается к более чем одному сценарию третье - это встроенная обработка ошибок спецификация со API позволяет возвращать xml сообщение rety
с кодом ошибки и её объяснением и четвёртое - это ряд расширения безопасности благодаря интеграции с протоколами vs Security качество транзакций со соответствует корпоративным стандартам со конфиденциальность и целостность внутри транзакции обеспечивая при этом шифрование на уровне сообщений Посмотрите на такое лаконичное изображение на экране вот безопасность на уровне сообщения soop аутентификационные данные в элементе заголовка и зашифрованном теле Какие же минусы у soop в наши дни многие разработчики содрогается при мысли о необходимости интеграции soop API по нескольким причинам первая причина - только xml соп сообщение содержит много метаданных и поддерживают только подробные xml срук ры для запроса и
ответов второе - это конечно тяжеловесного размера xml файлов со сервисы требуют большой пропускной способности третье - это узкоспециализированные знания создание серверов swop API требует глубокого понимания всех задействованных протоколов и их строгих правил и последнее - утомительное обновление сообщений в swap требуется дополнительные усилия для добавления или удаления свойств сообщения жёсткая схема soop замедляет принятие но а какие есть сценарии применения у soop в настоящее время архитектура соп чаще всего применяется для интеграции внутри предприятий или с их доверенными партнёрами Ну и главный кейс здесь - это в случае если вам нужна Надёжность передачи данных жёсткая структура соп а
также возможности в плане безопасности и авторизации делают его подходящим вариантом Для обеспечения соответствия формальному программному контракту между API и клиентом при соблюдении юридического контракта между поставщиком API и потребителем API Вот почему финансовые организации другие корпоративные пользователи часто выбирают soop даже сейчас Ну а теперь двигаемся к нашему любимому сту передача состояния представления представление данных в качестве ресурсов rest в расшифровке representational State Transfer - это самоо сатель ий архитектурный стиль API который определяется набором архитектурных ограничений и предназначен для широкого внедрения многим потребителями API сегодня это наиболее распространённый стиль API и он был впервые описан в 2000 году
Роем филдинга в его докторской диссертации рест делает доступными данные на стороне сервера предоставляя их в простых форматах чаще всего это J или xml но в целом вы тут не ограничены форматами как же он работает rest определён не так строго как soop и restful архитектура должна соответствовать шести архитектурным ограничениям Первое - Это единый интерфейс который позволяет единообразное взаимодействие с сервером вне зависимости от типа устройства или приложения второй вро - это отсутствие состояния то есть необходимое состояние обработки запроса содержится в самом запросе без того чтобы сервер хранил какие-либо относящиеся к сессии данные опять же ссылаясь на наше
недавнее видео про Stat и stateful советую посмотреть в чём же разница между сохранением состояния и независимостью от состояния также архитектурные ограничения - это кэширование и клиент-серверная архитектура которые позволяет независимое развитие двух сторон ещё многоуровневая система приложения и возможно для сервера обеспечивать исполняемый код на клиенте на самом деле некоторые сервисы соответствуют стандарту restful только в определённой степени они берут за основу стиль rpc разбивают более крупные службы на ресурсы и эффективно используют инфраструктуру http но Ключевое здесь - это гипермедиа иначе hos сокращённо от гипертекст как двигатель состояния приложения Hyper Application State и про него у нас тоже
видео отдельно есть по сути это означает то с каждым ответом rest API предоставляет метаданные которые связывают всю информацию о применении API это то что позволяет отделить клиента от сервера в результате и поставщик API и потребитель API могут развиваться Независимо И это не затрудняет их коммуникацию у Леонарда ричардсона даже есть такая штука Как модель зрелости API Посмотрите на экран она служит ориентиром для достижения действительно полных и полезных API hats - это Ключевая особенность rest и это дейст действительно то что делает рест самим собой поскольку большинство людей не использует йс они пользуются http rpc такое радикальное мнение
встретилось автору на Red Действительно йс - это самая зрелая версия rest это самая верхушка в пирамидке модели зрелости ричардсона Однако достижение этой цели достаточно затруднительно для этого требуется гораздо более продвинутые и интеллектуальные клиент API чем те которые обычно создаются и действуют в наши дни таким образом даже действительно хороший rest API сегодня не всегда соответствует стандарту Вот почему heos в основном служит ориентиром для долгосрочного развития дизайна restful API между rest и rpc действительно может находиться серая зона когда сервис реализует некоторые функции rest и некоторые rpc rest основан на ресурсе или существительном а не на действии то
есть не на глаголе Посмотрите на экран вот таблица с противоположными операциями для глагол ориентированного rpc и для реста который ориентирован на существительное если хотите можете на паузу поставить подробно рассмотреть но можно разобрать Последнюю строчку например Delete item Да мы что-то хотим удалить в случае rpc это будет пост запрос с такой командой Remove item с конкретным идентификатором айма А у реста это будет уже не пост а Delete конкретный item с конкретным дишни ком в rest всё делается с помощью http методов таких как Get Post Put Delete options и Patch Ну нескольких других иногда так Какие же
у реста плюсы Первое - это разделение клиента и сервера по возможности разделяя клиент и сервер rest обеспечивает лучшую абстракцию по сравнению с rpc система с уровнями абстракции способны инкапсулировать свои детали чтобы лучше идентифицировать И поддерживать свои свойства проще говоря внутренние детали реализации одного уровня не видны другим уровнем или внешним пользователям системы например в rest API клиенту не нужно знать как данные хранятся или обрабатываются на сервере внешне пользователи взаимодействуют с системой через стабильно и хоро определённые интерфейсы Что делает систему более надёжной и предсказуемой а изменения в реализации одного уровня намного реже влияют на другие уровни что
упрощает внесение изменений и поддержку системы поэтому rest API достаточно гибок чтобы развиваться с течением времени и при этом оставаться стабильной системой второй плюс - это открытость всё описывается связью между клиентом и сервером Так что для понимания как взаимодействовать с rest API не требуется никакая внешняя документация третье - это дружественно кэш rest - это единственный стиль который позволяет кэшировать данные на уровне http Благодаря повторному использованию множества http инструментов в то же время реализация кэширования в любом другом API потребует настройки дополнительного модуля кэширования Ну и последнее - это поддержка нескольких форматов возможность поддержки нескольких форматов хранения и
обмена данными одна из причин по которым rest в настоящее время преобладает в сфере создания общедоступных API плюс плюсами А какие же минусы у реста Первое - это нет единой структуры rest нет точного правильного способа создания rest API Как моделировать ресурсы и Какие ресурсы моделировать будет зависеть от каждого сценария это делает рест простым в теории но трудным иногда на практике второе большие полезные нагрузки СТ возвращает много богатых метаданных Так что клиент может понять всё необходимое состояние приложения Только из его ответов и эта болтливость не имеет большого значения для большой сетевой трубы с большой пропускной способ но
это не всегда так это как раз и стало ключевым движущим фактором для Facebook который придумал описание стиля Граф ql в 2012 году про него мы сейчас ещё поговорим и ещё один минус реста - это проблема чрезмерных или недостаточных данных ответы рест зачастую содержит либо слишком много данных либо их недостаточное количество и создают необходимость в дополнительном запросе Ну а что касается сценариев использования реста их очень много но Давайте перечислим максимально такие общие Первое - это API интерфейс управления API ориентированный на управление объектами в системе и предназначенный для многих потребителей распространены шире всего rest помогает таким API
обеспечивая сильную обнаруживаемые и хорошую документацию И тем самым вписывается в эту объект ную модель Ну и простые приложения управляемые ресурсами rest - Это очень хороший подход для подключения приложений которые управляются ресурсами которые не нуждаются в гибкости запросов почти все ограничения на самом деле можно обойти слава Богу уже RS много Где используется и чего только разработчики и архитекторы не придумали но в некоторых кейсах Граф ql будет лучше так что переходим к нему Граф ql запрос только необходимых данных для того чтобы вернуть что-то нужное требуется многократно вызывать rest API и вот чтобы изменить правила игры был изобретён
граф ql Граф ql - это синтаксис который описывает Как сделать точный запрос данных реализация Граф qul стоит того если задействована модель данных приложения с большим количеством сложных сущностей ссылающихся друг на друга как например в Фейсбуке есть мой профиль у него есть друзья у моих друзей есть друзья у них есть свои друзья а у этих друзей есть сообщения и посты я эти посты например могу видеть Ну и так далее В общем такие деревья со связями в наши дни экосистема Граф quel расширяется посредством библиотек и мощных инструментов таких как apol graphic ql и Graf ql Explorer как
же он работает этот gql graphql начинается с построения схемы которая представляет собой описание всех запросов которые возможно сделать в API Гра ql и всех типов данных которые они возвращают строить эту схему довольно сложно поскольку она требует строгой типизации на языке определение схемы schema Definition Language sdl клиент который располагает схемой перед отправкой запроса может проверить свой запрос и убедиться что сервер сможет ответить на него добравшись до бэнда операция в граф coil интерпретируется по всей схеме и разрешается с помощью данных для фронтенда отправив один массивный запрос на сервер API возвращает ответ в формате Jon с точно теми
же данными которые мы запросили не больше и не меньше в дополнение к крут операциям которые есть у restful graphql содержит также подписки которые позволяют в режиме реального времени получать уведомления от сервера тут мы конечно по верхам пробежались подробно ищите В отдельной статье нашей програф ql Ну а какие же плюсы у этого Граф Куля Первое - это типизированный схема Граф ql заранее публикует то что он может осуществить Что улучшает обнаруживаемые указывая клиенту на API Граф ql мы можем узнать какие запросы доступны второе Хорошо подходит для графических данных данные которые находятся в глубоких отношениях связанности но не
годятся для плоских данных третье - никаких версий лучшая практика управления версиями - это вообще не версионирование API В то время как рес предлагает несколько версий API граф использует единую развивающуюся версию которая обеспечивает непрерывный доступ к новым функциям и способствует более чистому и удобному в обслуживанию серверному коду также подробные сообщения об ошибках подобно soop Graf qul предоставляет подробную информацию о возникших ошибках сообщение об ошибке включает в себя все резольвера и ссылается на конкретную часть запроса на которой лежит ответственность Ну и гибкие разрешения Гра Co позволяет выборочно раскрывать определённые функции сохраняя при этом личную информацию между тем
архитектура rest не раскрывает данные порциями либо всё либо ничего То есть Хотим мы по профиля получить только возраст мы получаем не все данные от этого профиля а именно возраст того профиля который мы Запроси всё это конечно здорово но минусы У Граф Куля тоже есть и Первое - это проблема производительности Граф ql меняет сложность в обмен на действенность слишком большое количество вложенных полей в одном запросе может привести к перегрузке системы таким образом для сложных запросов лучшим вариантом останется rest также сложность кэширования поскольку Граф qul не переиспользовать семантику кэширования http кэширование требует приложения дополнительных усилий Ну и
конечно много самообразования перед разработкой Когда у них недостаточно времени чтобы разобраться в нишевых операциях Graf ql и sdl многие проекты решают пойти по известному уже понятно пути rest Ну и Давайте обсудим сценарий использования graphql первый - это мобильный API в этом случае важна производительность сети и оптимизация полезной нагрузки единичного сообщения игра fql предлагает более эффективную нагрузку данных для мобильных устройств конечно Graf coil - это не всегда Мах прямо да для мобильной разработки Но это будет довольно хорошим выбором и второй кейс - это сложная системы и микросервисы Граф ql способен скрыть сложность нескольких интегрированных систем лежащих
в основе его API агрегирующие или сторонних API которые расширились со временем Ну вот мы обсудили вкратце каждый из подходов Так какой же шаблон API лучше всего подойдёт для вас у каждого API проекта свои требования и потребности и обычно выбор архитектуры зависит от языка программирования среды разработки и ресурсов которые нужно сэкономить как человеческих так и финансовых понимая все компромиссы на которые подталкивает каждый Стиль архитектуры архитектор API могут выбрать из них наиболее подходящий конкретному проекту благодаря своей сильной связанности rpc хорошо годится для внутренних микросервисов но это не вариант для сильного внешнего API или API сервиса соп -
это хлопотно но его обширный функционал в плане безопасности по-прежнему незаменим иногда для биллинговый операций систем бронирования и платежей rest обладает самой высокой абстракцией и лучшим моделированием API но он как правило тяжелее в плане нагрузки на сеть и многословна недостаток Если вы работаете на мобильных устройствах большой плюс конечно реста в том что все умеют с ним работать игра в ql - это большой Шаг вперёд с точки зрения извлечения данных но не у всех достаточно времени и возможностей чтобы его осваивать Да и не всегда это имеет смысл в конце концов имеет смысл если есть возможность попробовать несколько
небольших сценариев с определённым архитектурным стилем и посмотреть подходит ли он и решает ли Ваши проблемы Если это так то Попробуйте расширить его применение и посмотреть как всё работает на Большом числе вариантов использования Ну а на этом всё спасибо что послушали эту статью надеюсь вам как и мне было интересно если понравилось видео то поставь ему лайк и подпишись на канал чтобы поддержать его мне будет лично Очень приятно если хочется денежкой поддержать канал то тоже так можно сделать это можно сделать на юмани одиночным переводом либо подписочка на бусте для особых гурманов и Конечно наша телега мы там
выкладываем аудио версии каждой статьи можно с заблокированным экраном на телефоне слушать пока идёшь куда-нибудь на работу или на учёбу и там есть некоторые статьи шпаргалки которых нет на Ютюбе Ну всё пока
