Мы знаем, что двум отдельным приложениям нужен посредник для связи друг с другом. Поэтому разработчики часто создают мосты (интерфейсы прикладного программирования), чтобы позволить одной системе получить доступ к информации или функциям другой системы.
Для быстрой и масштабной интеграции приложений API реализуются с использованием протоколов или спецификаций, определяющих семантику и синтаксис сообщений, передаваемых по сети. Эти спецификации составляют архитектуру API.
Со временем были выпущены различные архитектурные стили API. У каждого своя стандартизированная схема обмена данными, а обилие вариантов привело к бесконечным спорам о том, какой архитектурный стиль лучше.
Сегодня многие потребители API называют REST «покойся с миром» и приветствуют GraphQL, тогда как десять лет назад все было наоборот, REST был победителем над SOAP. Проблема этих взглядов в том, что они однобоки в выборе самой технологии, а не рассматривают, насколько ее реальные свойства и характеристики соответствуют текущей ситуации.
В этой статье мы сохраним объективную позицию, обсудим порядок появления четырех стилей API, сравним их сильные и слабые стороны и выделим сценарии, в которых каждый из них наиболее подходит.
Удаленный вызов процедур (RPC): вызов функции в другой системе.
удаленный вызов процедур— это спецификация, позволяющая удаленно выполнять функцию в другом контексте. RPC расширяет концепцию локальных вызовов процедур, но помещает ее в контекст HTTP API.
У оригинального XML-RPC были проблемы, потому что было очень сложно обеспечить тип данных полезной нагрузки XML. Итак, позже API RPC начал использовать более конкретную спецификацию JSON-RPC, которая считалась более простой альтернативой SOAP. gRPC — это последняя версия RPC, разработанная Google в 2015 году. Поддержка gRPC для балансировки нагрузки, отслеживания, проверки работоспособности и аутентификации является подключаемой, что очень удобно для подключения микросервисов.
Как работает RPC
Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщение и отправляет сообщение на сервер. После получения сообщения сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Заглушка сервера и заглушка клиента отвечают за сериализацию и десериализацию параметров.
Преимущества RPC
Простое и прямое взаимодействие.RPC использует GET для информации и POST для всего остального. Механизм взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
Функции, которые легко добавить.Если у нас есть новое требование к API, мы можем легко добавить еще одну конечную точку для выполнения этого требования:
- Написав новую функцию и поместив ее в конечную точку,
- Теперь клиент может обратиться к этой конечной точке и получить информацию, соответствующую установленным требованиям.
высокая производительность.Облегченные полезные нагрузки легко внедряются в сети, обеспечивающие высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сети рабочих станций. RPC может оптимизировать сетевой уровень и ежедневно отправлять большое количество сообщений между различными службами, что очень эффективно.
Недостатки RPC
Тесно связан с базовой системой. Уровень абстракции 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 являются сильными аргументами в пользу микросервисов. Благодаря поддержке HTTP 2 gRPC может оптимизировать сетевой уровень и ежедневно отправлять большое количество сообщений между различными службами с очень высокой эффективностью. Однако, если вашей целью является не высокая производительность сети, а стабильные соединения API между командами, публикующими уникальные микросервисы, REST обеспечит это.
Простой протокол доступа к объектам (SOAP): предоставление данных как услуги
SOAPЭто строго стандартизированный сетевой протокол связи в формате XML. Выпущенный через год после Microsoft XML-RPC, протокол SOAP многое унаследовал от него. Сначала они использовались параллельно, когда последовал REST, но вскоре REST выиграл гонку популярности.
Как работает МЫЛО
За форматом данных XML скрывается множество формальных вещей в сочетании с огромной структурой сообщений, что делает SOAP наиболее подробным стилем API.
SOAP-сообщения включают в себя:
-
Содержит тело запроса или ответа
-
заголовки (если в сообщении должны быть указаны какие-либо особые или дополнительные требования) и
-
Сбои уведомляют о любых ошибках, которые могли произойти во время обработки запроса.
Логика SOAP API написана на языке описания веб-служб (WSDL). Этот язык описания API определяет конечные точки и описывает все процессы, которые могут быть выполнены, что позволяет различным языкам программирования и IDE быстро устанавливать связь.
SOAP поддерживает обмен сообщениями с сохранением состояния и без него. В случае с сохранением состояния сервер, хранящий полученную информацию, может быть очень тяжелым. Но это разумно для операций с участием нескольких сторон и сложных транзакций.
Преимущества мыла
Независимость от языка и платформы. Встроенные возможности для создания веб-сервисов позволяют SOAP управлять коммуникациями и давать ответы, не зависящие от языка и платформы.
Привязка к различным транспортным протоколам. SOAP является гибким с точки зрения транспортных протоколов и может быть адаптирован ко многим ситуациям.
Встроенная обработка ошибок. Спецификация SOAP API позволяет возвращать повторное XML-сообщение с кодом ошибки и объяснением.
Множество расширений безопасности. При интеграции с протоколом WS-Security 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 не так жестко определен, как SOAP, существует шесть архитектурных ограничений, которым должна подчиняться архитектура RESTful.
-
Единый интерфейс: позволяет взаимодействовать с данным сервером единообразно, независимо от типа устройства или приложения.
-
нет статуса: необходимое состояние для обработки запроса, поскольку содержится в самом запросе, серверу не нужно хранить ничего, связанное с сеансом.
-
тайник
-
Клиент-серверная архитектура: позволяет любой стороне развиваться независимо
-
Программымногоуровневая система
-
Сервер предоставляет клиентуисполняемый кодСпособность
На самом деле, некоторые сервисы поддерживают RESTful только в определенной степени. По своей сути они похожи на RPC, разбивая более крупные службы на ресурсы и эффективно используя инфраструктуру HTTP. Но ключевой частью является использование гипермедиа, также известного как HATEOAS, сокращение от Hypertext As The Engine of Application State. По сути, это означает, что с каждым ответом REST API предоставляет метаданные со ссылками на всю необходимую информацию о том, как использовать API. Это то, что обеспечивает разделение клиента и сервера. Таким образом, как поставщики API, так и потребители API могут развиваться независимо друг от друга, не мешая их общению.
"HATEOAS — ключевая особенность REST. Это то, что делает REST действительно REST. Поскольку большинство людей не используют HATEOAS, они на самом деле используют HTTP RPC". Вот несколько радикальных мнений, высказанных на Reddit. На самом деле HATEOAS — самая зрелая версия REST. Однако для достижения этого требуются интеллектуальные API, которые намного более продвинуты, чем клиенты 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, не требуется никакой внешней документации.
дружественный к кэшу. Повторно используя множество инструментов HTTP, REST — единственный стиль, который позволяет кэшировать данные на уровне HTTP. Напротив, реализация кэширования в любом другом API требует настройки дополнительного модуля кэширования.
Поддерживает несколько форматов. Возможность поддерживать несколько форматов для хранения и обмена данными — одна из причин, по которой REST в настоящее время является основным выбором для создания общедоступных API.
Недостатки ОТДЫХА
Нет отдельной структуры 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, и всех типов, которые они возвращают. Построение схемы затруднено, поскольку требует строгой типизации на языке определения схемы (SDL).
Со схемой перед запросом клиенты могут проверить свой запрос по схеме, чтобы убедиться, что сервер может ответить на него. При достижении внутреннего приложения операции GraphQL интерпретируются по всей схеме и анализируются с данными из внешнего приложения. API отправляет большой запрос на сервер, возвращая ответ JSON с точной формой запрошенных нами данных.
Помимо операций RESTful CRUD, GraphQL имеет возможности подписки для получения уведомлений с сервера в режиме реального времени.
Преимущества GraphQL
типизированная схема. GraphQL заранее объявляет, что он может сделать, что улучшает его обнаруживаемость, указывая клиентам на GraphQL API, мы можем узнать, какие запросы есть.
Хорошо работает с графическими данными. Связи данных глубокие, но не подходят для плоских данных.
нет контроля версий. Лучшей практикой для версионирования является вообще не версионирование 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 — это большой шаг вперед в обработке данных, но не у всех есть время и энергия, чтобы освоить его.
В конце концов, имеет смысл попробовать несколько небольших вариантов использования с определенным стилем, чтобы увидеть, подходит ли он вашему варианту использования и решает ли он вашу проблему. Если это так, попробуйте расширить его, чтобы увидеть, подходит ли он для большего количества вариантов использования.
оригинал:blog.zhangbing.site
источник:levelup.gitconnected.com
Автор: AltexSoft Inc.