API-интерфейсы соединяют приложения с помощью четких протоколов и архитектур. Архитектура API — это набор правил для создания программных интерфейсов. Правила определяют, как предоставлять пользователям функциональные возможности сервера. Тип архитектуры определяет правила и структуры, управляющие API.
Существует множество различных типов архитектуры API, от REST до RPC. Изучение их структуры и состава поможет вам выбрать один из них для вашего приложения.
1. ОТДЫХ
REST API являются современными и являются самой популярной архитектурой API, используемой разработчиками. ОТДЫХ (передача репрезентативного состояния) — это архитектура, используемая для разработки клиент-серверных приложений. Это не протокол и не стандарт, поэтому вы можете реализовать его по-разному. Этот аспект увеличивает вашу гибкость как разработчика.
REST позволяет получить доступ к запрошенным данным, хранящимся в базе данных. Вы можете выполнять основные функции CRUD с помощью REST API. Когда клиенты запрашивают контент через RESTful API, они должны использовать правильные заголовки и параметры. Заголовки содержат полезные метаданные для идентификации ресурса, такие как коды состояния и авторизация.
Информация, передаваемая через HTTP, может быть в формате JSON, HTML, XML или в виде обычного текста. JSON — это наиболее часто используемый формат файлов для REST API. JSON не зависит от языка и читается людьми.
2. МЫЛО
Простой протокол доступа к объектам (SOAP) — это официальный протокол API. Консорциум World Wide Web (W3C) поддерживает протокол SOAP, который является одной из самых ранних архитектур API. Его дизайн упрощает взаимодействие между приложениями, созданными на разных языках и платформах.
Формат SOAP описывает API с использованием языка описания веб-сервисов (WSDL). Он написан на расширенном языке разметки (XML). Формат налагает встроенные стандарты соответствия, которые повышают безопасность, согласованность, изоляцию и надежность. Эти свойства обеспечивают надежность транзакций базы данных, что делает SOAP более удобным для корпоративной разработки.
Когда пользователь запрашивает контент через SOAP API, он проходит через протоколы стандартного уровня. Ответ находится в формате XML, который могут прочитать люди и машины. Как и REST API, SOAP API не кэшируют и не хранят информацию. Если вам нужны данные позже, вам нужно сделать еще один запрос.
SOAP поддерживает обмен данными как с сохранением состояния, так и без него.
3. GraphQL
GraphQL — это язык запросов для API. Это среда выполнения на стороне сервера, которая выполняет запросы на основе определенного набора данных. GraphQL имеет определенные варианты использования. Его архитектура позволяет вам объявлять конкретную информацию, которая вам нужна.
В отличие от архитектуры REST, где HTTP обрабатывает клиентские запросы и ответы, GraphQL запрашивает данные с помощью запросов. Служба GraphQL определяет типы и поля этих типов, а затем предоставляет функции для каждого поля и типа.
Служба получает GraphQL-запросы для проверки и выполнения. Во-первых, он проверяет запрос, чтобы убедиться, что он ссылается на определенные типы и определенные поля. Затем он запускает связанные функции для получения желаемого результата.
GraphQL отлично подходит для определенных случаев использования, таких как выборка данных из нескольких источников. Вы также можете контролировать выборку данных и регулировать пропускную способность для небольших устройств.
4. Апач Кафка
Апач Кафка — это распределенная платформа, поддерживающая потоковую передачу событий. Потоковая передача событий — это процесс сбора данных в режиме реального времени из источников. Источниками могут быть базы данных, серверы или программные приложения. Система Kafka состоит из серверов и клиентов. Связь происходит через сетевой протокол TCP.
Вы можете развернуть систему на оборудовании, виртуальных машинах и контейнерах. Вы можете делать это локально и в облачных средах. Система Apache Kafka собирает данные, обрабатывает их и реагирует на них в режиме реального времени. Он также может направлять данные в предпочтительное место назначения в режиме реального времени. Kafka собирает и сохраняет данные в системе, которые вы можете получить позже для использования.
Kafka поддерживает непрерывный поток и интеграцию данных. Это гарантирует, что информация окажется в нужном месте и в нужное время. Потоковая передача событий может применяться во многих случаях, когда требуются потоки данных в реальном времени. К ним относятся финансовые учреждения, здравоохранение, правительство, транспортная отрасль и компании, производящие компьютерное программное обеспечение.
5. АсинхронныйAPI
АсинхронныйAPI — это инициатива с открытым исходным кодом, которая помогает создавать и поддерживать архитектуры, управляемые событиями. Его спецификации имеют много общего со спецификациями OpenAPI. AsyncAPI, по сути, является адаптацией и улучшением спецификаций OpenAPI с некоторыми отличиями.
Архитектура AsyncAPI объединяет API REST и API, управляемые событиями. Его схемы для обработки запросов и ответов аналогично API событий. AsyncAPI предоставляет спецификации для описания и документирования асинхронных приложений в машиночитаемом виде. формат. Он также предоставляет такие инструменты, как генераторы кода, облегчающие пользователям их реализацию.
AsyncAPI улучшает текущее состояние управляемой событиями архитектуры (EDA). Цель состоит в том, чтобы упростить работу с EDA, как с REST API. Инициатива AsyncAPI предоставляет документацию и код, поддерживающие управление событиями. Большинство процессов, используемых в REST API, относятся к управляемым событиями/асинхронным API.
Использование спецификации AsyncAPI для документирования систем, управляемых событиями, жизненно важно. Он регулирует и поддерживает согласованность и эффективность между командами, работающими над управляемыми событиями проектами.
6. Удаленный вызов процедур (RPC)
RPC — это программный коммуникационный протокол, который позволяет обмениваться данными между различными программами в сети. Например, программа может запросить информацию с другого компьютера в сети. Он не должен придерживаться сетевых протоколов. Вы можете использовать RPC для вызова процессов в удаленных системах так же, как в локальной системе.
RPC работает по модели клиент-сервер. Клиентская программа запрашивает, а серверная программа отвечает сервисом. RPC работают синхронно. Когда программа отправляет запрос, она остается приостановленной до тех пор, пока не получит ответ от сервера.
RPC лучше всего подходят для распределенных систем. Они лучше всего подходят для командных систем и имеют облегченную полезную нагрузку, повышающую производительность.
Как выбрать правильную архитектуру API
Правильная архитектура API зависит от вашего варианта использования. Архитектура определяет методологию разработки API и то, как он будет работать. Архитектурный дизайн API определяет его компоненты и взаимодействия.
Принимайте архитектурные решения перед проектированием и разработкой API. Определите технические требования к API, уровню, управлению жизненным циклом и безопасности. Проекты архитектуры API содержат структурные слои. Уровни направляют разработку и гарантируют, что созданный API служит своей цели.
