Это продолжение серии статей, в которых я кратко освещаю основные моменты конкретной темы проектирования системной архитектуры. Первую статью можно прочитать здесь Архитектура API — это набор правил, протоколов и инструментов, которые определяют, как должны взаимодействовать программные компоненты. Архитектура API предназначена не только для облегчения коммуникации; речь также идет о том, чтобы эта связь была эффективной, безопасной и масштабируемой. Хорошо спроектированная архитектура API может значительно повысить производительность системы, а плохо спроектированная может привести к узким местам, уязвимостям безопасности и кошмарам при обслуживании. Различные стили архитектуры API Наиболее распространенные стили дизайна API: (передача репрезентативного состояния) — наиболее часто используемый стиль, использующий стандартные методы и протоколы HTTP. Он основан на таких принципах, как отсутствие гражданства, архитектура клиент-сервер и возможность кэширования. Он часто используется между внешними клиентами и внутренними службами. REST — это язык запросов для API. В отличие от REST, который предоставляет фиксированный набор конечных точек для каждого ресурса, GraphQL позволяет клиентам запрашивать именно те данные, которые им нужны, сокращая чрезмерную выборку. GraphQL — это протокол, обеспечивающий двустороннюю связь по TCP. Клиенты используют веб-сокеты для получения обновлений в реальном времени от серверных систем. WebSocket — это механизм, который позволяет одной системе уведомлять другую систему о конкретных событиях в режиме реального времени. Это определяемый пользователем обратный вызов HTTP. Webhook — это протокол, который одна служба может использовать для запроса процедуры/метода у службы, расположенной на другом компьютере в сети. Обычно он предназначен для высокоскоростной связи с малой задержкой. RPC (gRPC) — это протокол обмена структурированной информацией для реализации веб-сервисов. Он основан на XML и известен своей надежностью и функциями безопасности и в настоящее время считается устаревшим протоколом. SOAP Давайте рассмотрим каждый протокол отдельно со всеми его плюсами, минусами и вариантами использования. ОТДЫХ — это архитектурный стиль, в котором используются стандартные соглашения и протоколы, что упрощает понимание и реализацию. Его природа без сохранения состояния и использование стандартных методов HTTP делают его популярным выбором для создания веб-API. REST Хотя REST долгое время был фактическим стандартом для создания API, появились и другие стили, такие как GraphQL, предлагающие разные парадигмы для запросов и манипулирования данными. : XML, JSON, HTML, обычный текст. Формат : HTTP/HTTPS. Транспортный протокол Ключевые понятия и характеристики : В REST все является ресурсом. Ресурс — это объект с типом, связанными с ним данными, связями с другими ресурсами и набором методов, которые с ним работают. Ресурсы идентифицируются по их URI (обычно URL). Ресурс . Службы REST часто сопоставляются непосредственно с операциями CRUD (создание, чтение, обновление, удаление) над ресурсами. Операции CRUD . Системы REST используют стандартные методы HTTP: Методы HTTP GET: Получить ресурс. POST: Создайте новый ресурс. PUT/PATCH: обновить существующий ресурс. УДАЛЕНИЕ: удалить ресурс. . API-интерфейсы REST используют стандартные коды состояния HTTP для обозначения успеха или неудачи запроса API: Коды состояния 2xx – Признание и успех 200 - ОК 201 – Создано 202 – Принято 3xx — перенаправление 301 - Переехал навсегда 302 - Найдено 303 - См. другое 4xx — ошибка клиента ошибка 400, неверный запрос 401 – Несанкционированный 403 - Запрещено 404 Не Найдено 405 - Метод не разрешен 5xx — ошибка сервера 500 - внутренняя ошибка сервера 501 - Не реализовано 502 Неверный шлюз 503 Сервис недоступен Ошибка 504 Время ответа сервера истекло : каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания и обработки запроса. Сервер не должен хранить ничего о состоянии клиента между запросами. Без сохранения состояния : REST основан на модели клиент-сервер. Клиент отвечает за пользовательский интерфейс и работу, а сервер отвечает за обработку запросов, обработку бизнес-логики и хранение данных. Клиент-Сервер : ответы сервера могут кэшироваться клиентом. Сервер должен указать, кэшируется ли ответ или нет. Кэшируемый : клиент обычно не может определить, подключен ли он напрямую к конечному серверу или к посреднику. Промежуточные серверы могут улучшить масштабируемость системы, обеспечивая балансировку нагрузки и предоставляя общий кэш. Многоуровневая система Hypermedia As the Engine Of Application Stat — это принцип веб-службы REST, который позволяет клиентам взаимодействовать с веб-приложением и перемещаться по нему, полностью основываясь на гипермедиа, динамически предоставляемом сервером в его ответах, обеспечивая слабую связь и возможность обнаружения. HATEOAS: Случаи использования . Многие веб-сервисы раскрывают свою функциональность через REST API, что позволяет сторонним разработчикам интегрировать и расширять свои сервисы. Веб-сервисы . Мобильные приложения часто взаимодействуют с внутренними серверами, используя REST API для получения и отправки данных. Мобильные приложения . SPA используют REST API для динамической загрузки контента без необходимости полного обновления страницы. Одностраничные приложения (SPA) Системы внутри организации могут обмениваться данными и обмениваться ими с помощью REST API. Интеграция между системами. Пример Запрос ПОЛУЧИТЬ «/пользователь/42» Ответ { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } } ГрафQL предлагает более гибкий, надежный и эффективный подход к созданию API, особенно в сложных системах или когда интерфейсу требуется высокая гибкость. Он перекладывает часть ответственности с сервера на клиента, позволяя клиенту указывать свои требования к данным. GraphQL Хотя это не замена REST во всех сценариях, во многих ситуациях он предлагает убедительную альтернативу, особенно когда приложения становятся все более сетевыми и распределенными. : JSON Формат : HTTP/HTTPS. Транспортный протокол Ключевые понятия и характеристики : позволяет клиентам запрашивать необходимые им данные, позволяя получить всю необходимую информацию в одном запросе. Язык запросов для API : API GraphQL организованы по типам и полям, а не по конечным точкам. Он использует строгую систему типов для определения возможностей API. Все типы, представленные в API, записаны в схеме с использованием языка определения схемы GraphQL (SDL). Система типов . В отличие от REST, где у вас может быть несколько конечных точек для разных ресурсов, в GraphQL вы обычно предоставляете одну конечную точку, которая выражает полный набор возможностей службы. Единая конечная точка : на стороне сервера резолверы собирают данные, описанные в запросе. Резолверы . Помимо простого запроса данных, GraphQL включает встроенную поддержку обновлений в реальном времени с использованием подписок. Обновления в реальном времени с помощью подписок : к серверу GraphQL можно запросить типы, которые он поддерживает. Это создает прочный контракт между клиентом и сервером, позволяя использовать инструменты и улучшать проверку. Интроспективный Случаи использования . Для приложений (особенно мобильных) с критической пропускной способностью необходимо минимизировать объем данных, получаемых с сервера. Гибкие интерфейсы . Можно добавить уровень GraphQL для агрегирования данных из этих сервисов в единый API, если у вас есть несколько микросервисов. Агрегирование микросервисов . Благодаря своей системе подписки GraphQL может отлично подойти для приложений, которым нужны данные в реальном времени, таких как чат-приложения, спортивные новости в прямом эфире и т. д. Приложения реального времени . При использовании REST вам часто требуется обновлять версии API после внесения изменений. С GraphQL клиенты запрашивают только необходимые данные, поэтому добавление новых полей или типов не приводит к критическим изменениям. API без версий Пример Запрос GET «/graphql?query=user(id:42){ name role { id name } }» Ответ { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } } Вебсокет обеспечивают полнодуплексный канал связи через одно долгоживущее соединение, позволяя обмениваться данными в реальном времени между клиентом и сервером. Это делает его идеальным для интерактивных и высокопроизводительных веб-приложений. WebSockets : двоичный Формат : TCP Транспортный протокол Ключевые понятия и характеристики . В отличие от традиционной модели запрос-ответ, WebSockets предоставляет полнодуплексный канал связи, который остается открытым, что позволяет обмениваться данными в реальном времени. Постоянное соединение : WebSocket запускается как HTTP-запрос, который затем обновляется до соединения WebSocket, если сервер его поддерживает. Это делается через заголовок «Upgrade». Обновление рукопожатия : после установления соединения данные передаются в виде кадров. Через эти кадры можно отправлять как текстовые, так и двоичные данные. Кадры : WebSockets позволяют осуществлять прямую связь между клиентом и сервером без необходимости открытия нового соединения для каждого обмена. Это приводит к более быстрому обмену данными. Низкая задержка : и клиент, и сервер могут отправлять сообщения друг другу независимо. Двунаправленный : после первоначального соединения для отправки кадров данных требуется меньше байтов, что приводит к меньшим накладным расходам и повышению производительности, чем многократное установление HTTP-соединений. Меньше накладных расходов . WebSockets поддерживают подпротоколы и расширения, что позволяет использовать стандартизированные и пользовательские протоколы поверх базового протокола WebSocket. Протоколы и расширения Случаи использования : многопользовательские игры в реальном времени, в которых действия игроков должны немедленно отражаться на других игроках. Онлайн-игры : такие приложения, как Google Docs, где несколько пользователей могут редактировать документ одновременно и видеть изменения друг друга в режиме реального времени. Инструменты для совместной работы : платформы для торговли акциями, где цены на акции необходимо обновлять в режиме реального времени. Финансовые приложения : любое приложение, в котором пользователям необходимо получать уведомления в режиме реального времени, например, платформы социальных сетей или приложения для обмена сообщениями. Уведомления : новостные веб-сайты или платформы социальных сетей, где новые сообщения или обновления транслируются пользователям в прямом эфире. Прямые каналы Пример Запрос ПОЛУЧИТЕ «ws://сайт:8181» Ответ HTTP/1.1 101 Протоколы коммутации Вебхук — это определяемый пользователем обратный вызов HTTP, запускаемый определенными событиями веб-приложения, позволяющий обновлять данные в реальном времени и осуществлять интеграцию между различными системами. Webhook : XML, JSON, обычный текст. Формат : HTTP/HTTPS. Транспортный протокол Ключевые понятия и характеристики : веб-перехватчики обычно используются для обозначения того, что произошло событие. Вместо регулярного запроса данных веб-перехватчики предоставляют данные по мере их поступления, переворачивая традиционную модель запроса-ответа с ног на голову. Управляемый событиями . Вебхуки, по сути, представляют собой определяемый пользователем механизм обратного вызова. Когда происходит определенное событие, исходный сайт выполняет обратный вызов HTTP к URI, предоставленному целевым сайтом, который затем выполняет определенное действие. Механизм обратного вызова : при срабатывании вебхука исходный сайт отправит данные (полезную нагрузку) на целевой сайт. Эти данные обычно имеют форму JSON или XML. Полезная нагрузка : веб-перехватчики позволяют приложениям получать данные в режиме реального времени, что делает их более быстрыми. В режиме реального времени : пользователи или разработчики обычно могут определить, о каких конкретных событиях они хотят получать уведомления. Настраиваемый . Поскольку веб-перехватчики включают в себя обратные вызовы к определяемым пользователем конечным точкам HTTP, они могут создавать проблемы безопасности. Крайне важно убедиться, что конечная точка безопасна, данные проверены и, возможно, зашифрованы. Безопасность Случаи использования : запуск сборок и развертываний при отправке кода или объединении запроса на включение. Непрерывная интеграция и развертывание (CI/CD) : уведомление нижестоящих систем при обновлении, публикации или удалении контента. Системы управления контентом (CMS) : информирование платформ электронной коммерции о результатах транзакций, таких как успешные платежи, неудачные транзакции или возвраты средств. Платежные шлюзы : получение уведомлений о новых публикациях, упоминаниях или других соответствующих событиях на платформах социальных сетей. Интеграция с социальными сетями : устройства или датчики могут запускать веб-перехватчики для уведомления других систем или служб о конкретных событиях или показаниях данных. IoT (Интернет вещей) Пример Запрос ПОЛУЧИТЕ « » https://external-site/webhooks?url=http://site/service-h/api&name=name Ответ { "webhook_id": 12 } RPC и gRPC (удаленный вызов процедур) — это протокол, который позволяет программе выполнять процедуру или подпрограмму в другом адресном пространстве, обеспечивая бесперебойную связь и обмен данными между распределенными системами. RPC (Google RPC) — это современная платформа с открытым исходным кодом, построенная на основе RPC, которая использует HTTP/2 для транспорта и буферы протоколов в качестве языка описания интерфейса, предоставляя такие функции, как аутентификация, балансировка нагрузки и многое другое для обеспечения эффективной и надежной связи. между микросервисами. gRPC ПКП : JSON, XML, Protobuf, Thrift, FlatBuffers. Формат : Разный Транспортный протокол Ключевые понятия и характеристики : RPC позволяет программе вызвать выполнение процедуры (подпрограммы) в другом адресном пространстве (обычно на другом компьютере в общей сети). Это похоже на вызов функции, выполняемой на другой машине, отличной от машины вызывающей стороны. Определение : в контексте RPC заглушки — это фрагменты кода, созданные инструментами, которые позволяют локальным и удаленным вызовам процедур выглядеть одинаково. У клиента есть заглушка, которая выглядит как удаленная процедура, а у сервера есть заглушка, которая распаковывает аргументы, вызывает фактическую процедуру, а затем упаковывает результаты для отправки обратно. Заглушки : традиционные вызовы RPC блокируются, то есть клиент отправляет запрос на сервер и блокируется в ожидании ответа от сервера. Синхронный по умолчанию : многие системы RPC позволяют различным реализациям клиента и сервера взаимодействовать независимо от языка, на котором они написаны. Нейтральность языка : RPC часто требует, чтобы клиент и сервер знали вызываемую процедуру, ее параметры и тип возвращаемого значения. Тесная связь Случаи использования : RPC обычно используется в распределенных системах, где части системы распределены по разным машинам или сетям, но должны взаимодействовать так, как если бы они были локальными. Распределенные системы : NFS (сетевая файловая система) является примером RPC, выполняющих файловые операции удаленно. Сетевые файловые системы Пример Запрос { "method": "addUser", "params": [ "Alex" ] } Ответ { "id": 42, "name": "Alex", "error": null } gRPC : Protobuf Формат : HTTP/2. Транспортный протокол Ключевые понятия и характеристики : gRPC — это платформа RPC с открытым исходным кодом, разработанная Google. Он использует HTTP/2 для транспорта, буферы протокола (Protobuf) в качестве языка описания интерфейса, а также обеспечивает аутентификацию, функции балансировки нагрузки и многое другое. Определение : это независимый от языка и платформы расширяемый механизм сериализации структурированных данных. С помощью gRPC вы определяете методы обслуживания и типы сообщений с помощью Protobuf. Буферы протокола : gRPC разработан для обеспечения низкой задержки и высокой пропускной способности. HTTP/2 позволяет мультиплексировать несколько вызовов по одному соединению и снижает накладные расходы. Производительность : gRPC поддерживает потоковую передачу запросов и ответов, что позволяет использовать более сложные случаи, такие как долгоживущие соединения, обновления в реальном времени и т. д. Потоковая передача : gRPC позволяет клиентам указывать, как долго они будут ждать завершения RPC. Сервер может проверить это и решить, следует ли завершить операцию или прервать ее, если она, вероятно, займет слишком много времени. Сроки/тайм-ауты : gRPC предназначен для поддержки подключаемой аутентификации, балансировки нагрузки, повторных попыток и т. д. Подключаемый : как и RPC, gRPC не зависит от языка. Однако с помощью Protobuf и инструментов gRPC легко генерировать клиентский и серверный код на нескольких языках. Языковая нейтральность Случаи использования : gRPC обычно используется в архитектурах микросервисов из-за его характеристик производительности и возможности легко определять контракты обслуживания. Микросервисы . Благодаря поддержке потоковой передачи gRPC подходит для приложений реального времени, где серверы передают данные клиентам в режиме реального времени. Приложения реального времени : преимущества производительности и возможности потоковой передачи gRPC делают его подходящим для мобильных клиентов, взаимодействующих с серверными службами. Мобильные клиенты Пример message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); } МЫЛО , что означает Simple Object Access Protocol, представляет собой протокол обмена структурированной информацией для реализации веб-сервисов в компьютерных сетях. Это протокол на основе XML, который позволяет программам, работающим в разных операционных системах, взаимодействовать друг с другом. SOAP : XML Формат : HTTP/HTTPS, JMS, SMTP и др. Транспортный протокол Ключевые понятия и характеристики : сообщения SOAP форматируются в XML и содержат следующие элементы: На основе XML : корневой элемент сообщения SOAP, определяющий XML-документ как сообщение SOAP. Конверт : содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Заголовок : содержит данные XML, составляющие отправляемое сообщение. Тело : дополнительный элемент Fault, предоставляющий информацию об ошибках при обработке сообщения. Fault : SOAP может использоваться с любой моделью программирования и не привязан к какой-то конкретной. Нейтральность : он может работать в любой операционной системе и на любом языке. Независимость : каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания и обработки запроса. Без сохранения состояния : элемент Fault в сообщении SOAP используется для сообщения об ошибках. Встроенная обработка ошибок : работает на основе четко определенных стандартов, включая саму спецификацию SOAP, а также связанных стандартов, таких как WS-ReliableMessaging для обеспечения доставки сообщений, WS-Security для безопасности сообщений и т. д. Стандартизированный Случаи использования . SOAP часто используется в корпоративных условиях из-за его надежности, расширяемости и способности преодолевать брандмауэры и прокси-серверы. Корпоративные приложения . Многие веб-службы, особенно старые, используют SOAP. Сюда входят услуги, предлагаемые крупными компаниями, такими как Microsoft и IBM. Веб-службы . Встроенная безопасность и расширяемость SOAP делают его хорошим выбором для финансовых транзакций, где целостность и безопасность данных имеют первостепенное значение. Финансовые транзакции . Телекоммуникационные компании могут использовать SOAP для таких процессов, как выставление счетов, когда различные системы должны надежно взаимодействовать. Телекоммуникации Пример Запрос <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserRequest> <m:Name>Alex</m:Name> </m:AddUserRequest> </soap:Body> </soap:Envelope> Ответ <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserResponse> <m:Id>42</m:Id> <m:Name>Alex</m:Name> </m:AddUserResponse> </soap:Body> </soap:Envelope> Заключение Ландшафт стилей архитектуры API разнообразен и предлагает различные подходы, такие как REST, SOAP, RPC и другие, каждый из которых имеет уникальные сильные стороны и варианты использования, что позволяет разработчикам выбирать наиболее подходящую парадигму для построения масштабируемой, эффективной и надежной интеграции между различным программным обеспечением. компоненты и системы.
