REST, Webhooks, GraphQL, gRPC и другие: выбор идеальной архитектуры API для вашего…

Выбор правильной архитектуры API имеет решающее значение для создания эффективных приложений. В этой статье рассматриваются и сравниваются популярные архитектуры API, включая REST, Webhooks, SOAP, GraphQL, WebSockets, gRPC, MQTT, AMQP, Server-Sent Events, EDI и EDA. Понимая их характеристики и учитывая различные факторы, вы можете принять обоснованное решение, соответствующее требованиям вашего проекта. Понимание характеристик и соображений каждой архитектуры необходимо для создания эффективных систем связи. В этой статье мы сравним основные архитектуры API и предоставим информацию, которая поможет вам принять обоснованное решение.

Согласно Postman 2022 State of the API Report, хотя REST остается наиболее широко используемой архитектурой API, он немного уступил место новичкам. В опросе этого года 89% респондентов выбрали REST, по сравнению с 92% в предыдущем году. Webhooks (35% против 33% в прошлом году), GraphQL (28% против 24%) и gRPC (11% против 8%) в этом году набрали популярность. gRPC обычно используется для внутренних микросервисов, а GraphQL используется для объединения разрозненных источников данных.

ОТДЫХ

REST — это архитектурный стиль, используемый для разработки сетевых приложений, обычно в веб-сервисах и API. Системы RESTful моделируют приложение как набор ресурсов, которые идентифицируются уникальными URL-адресами и взаимодействуют с ними с помощью четко определенных методов HTTP. REST не имеет состояния, то есть каждый запрос содержит всю необходимую информацию, а ресурсы представлены в стандартизированном формате, таком как JSON или XML.

RESTful API широко используются для создания веб-сервисов и не зависят от языка. При разработке RESTful API важно определить ресурсы, установить согласованные структуры URL-адресов, использовать соответствующие методы HTTP и предоставить четкие рекомендации для клиентов.

Вебхуки

Веб-перехватчики обеспечивают управляемую событиями связь для приложений. Вместо того, чтобы клиенты постоянно запрашивали обновления, веб-перехватчик позволяет серверу отправлять запрос POST на определенный URL-адрес (конечную точку веб-перехватчика) при возникновении определенного события. Это позволяет клиентам получать немедленные уведомления или инициировать определенные действия. Веб-перехватчики обычно используются в интеграциях, веб-API и архитектурах, управляемых событиями.

МЫЛО

SOAP — это протокол обмена сообщениями, используемый для облегчения связи между программами, работающими в разных операционных системах или использующих разные языки программирования. Сообщения SOAP обычно отправляются в виде XML-документов, содержащих конверт, заголовок и тело, с поддержкой различных типов данных. SOAP обеспечивает независимость от протокола, расширяемость, встроенную обработку ошибок и контракт через язык описания веб-служб (WSDL), чтобы клиенты понимали доступные операции, форматы сообщений и протоколы. Хотя SOAP часто используется в корпоративных средах, более простые альтернативы, такие как REST и gRPC, чаще используются для современных реализаций веб-сервисов из-за их меньшей сложности и многословности.

ГрафQL

GraphQL — это язык запросов и среда выполнения для API (интерфейсов прикладного программирования), разработанный Facebook. Он приобрел популярность благодаря своей гибкости и эффективности при выборке данных. С GraphQL клиенты могут запрашивать определенные структуры данных и извлекать только те данные, которые им нужны, уменьшая количество избыточной или недостаточной выборки данных. Он позволяет клиентам определять запросы и мутации в иерархическом порядке и предоставляет мощную систему самоанализа для запросов к схеме.

Веб-сокеты

WebSockets обеспечивают полнодуплексные каналы связи по одному TCP-соединению. В отличие от традиционного HTTP, который следует модели «запрос-ответ», WebSockets обеспечивает двустороннюю связь между клиентами и серверами в режиме реального времени. Эта технология обычно используется в приложениях, требующих обновлений в реальном времени или интерактивных функций, таких как чат-приложения, средства совместного редактирования и игры в реальном времени.

gRPC

gRPC означает «Удаленный вызов процедур Google» и представляет собой среду удаленного вызова процедур (RPC) с открытым исходным кодом. Он позволяет вам определять службы и типы сообщений, используя протокольные буферы (protobuf), независимый от языка формат двоичной сериализации. gRPC поддерживает различные языки программирования и предоставляет такие функции, как двунаправленная потоковая передача, управление потоком, аутентификация и балансировка нагрузки. Он известен своей высокопроизводительной и эффективной связью между клиентами и серверами.

MQTT

MQTT (Message Queuing Telemetry Transport) — это упрощенный протокол обмена сообщениями с публикацией и подпиской, предназначенный для использования с ограниченными устройствами и сетями с низкой пропускной способностью и высокой задержкой. Он обычно используется в сценариях Интернета вещей (IoT), где устройствам необходимо публиковать сообщения с данными и подписываться на них. MQTT следует архитектуре на основе брокера, в которой центральный брокер облегчает связь между издателями и подписчиками.

AMQP

AMQP (Advanced Message Queued Protocol) — это промежуточный протокол, обеспечивающий безопасный и асинхронный обмен сообщениями между программными системами. Он поддерживает шаблоны очередей и маршрутизации сообщений, предоставляя возможность направлять сообщения в определенные очереди. AMQP использует обмены для маршрутизации сообщений в очереди на основе правил привязки и поддерживает различные шаблоны связи, включая публикацию/подписку, двухточечную связь, запрос/ответ и рабочие очереди. Он подходит для надежной и масштабируемой передачи сообщений в корпоративных системах обмена сообщениями, распределенных системах и сценариях интеграции. AMQP также предоставляет механизмы аутентификации, шифрования и подтверждения сообщений для обеспечения безопасной и надежной доставки сообщений.

События, отправленные сервером

Server-Sent Events (SSE) — это веб-технология, обеспечивающая однонаправленную связь в режиме реального времени между клиентом и сервером. SSE позволяет серверу отправлять обновления клиенту через одно долгоживущее HTTP-соединение. Он подходит для сценариев, в которых требуется обновление данных в режиме реального времени, таких как прямые трансляции, приложения чата и системы мониторинга в реальном времени.

SSE использует существующую инфраструктуру HTTP, хорошо поддерживается современными веб-браузерами и требует минимальной настройки как на стороне сервера, так и на стороне клиента. SSE обеспечивает эффективный и простой способ реализации обновлений в реальном времени в веб-приложениях, обеспечивая более интерактивный и динамичный пользовательский интерфейс.

ЭОД

Электронный обмен данными (EDI) — это стандартный протокол, используемый для обмена деловыми документами между компьютерными системами. Он позволяет автоматизировать бизнес-процессы, исключает ручной ввод данных и повышает эффективность. EDI определяет конкретные форматы сообщений и элементы данных для обеспечения согласованности и совместимости между различными торговыми партнерами. Сообщения EDI могут передаваться с использованием различных транспортных протоколов, включая сети с добавленной стоимостью (VAN), AS2, FTP и веб-службы. Торговые партнеры также заключают соглашения, определяющие технические и бизнес-требования для обмена данными.

ЭДА

EDA (архитектура, управляемая событиями) — это шаблон архитектуры программного обеспечения, который подчеркивает поток событий и реакции, вызванные этими событиями. Производители событий генерируют события на основе определенных триггеров или условий, а потребители событий — это компоненты или системы, которые реагируют на события. EDA часто включает в себя брокера событий или шину, которая служит центральным узлом для маршрутизации и распределения событий. Эта архитектура обеспечивает масштабируемость и оперативность, позволяя системам реагировать на события в режиме реального или близкого к реальному времени. EDA особенно полезен в таких областях, как финансовые услуги, Интернет вещей, логистика и архитектуры, управляемые событиями.

Сравнительная таблица архитектуры API

• Протокол связи. Используемый протокол связи, например HTTP, протокол WebSocket или протокол gRPC, определяет правила и соглашения для обмена данными между клиентом и сервером.
• Стиль общения. Стиль общения, будь то запрос-ответ, управление событиями или публикация-подписка, влияет на то, как происходит обмен данными между клиентом и сервером.
• Формат данных. Выбор формата данных, например JSON, XML или протокольные буферы, влияет на взаимодействие, представление данных и простоту анализа между клиентом и сервером.
• Масштабируемость. Масштабируемость имеет решающее значение для приложений, рассчитанных на высокие нагрузки. Такие архитектуры, как REST, gRPC, MQTT и AMQP, предлагают хорошие возможности масштабирования, позволяя системам справляться с растущим спросом за счет горизонтального или вертикального масштабирования.
• Связь в режиме реального времени. Связь в режиме реального времени необходима для приложений, требующих немедленных обновлений и уведомлений. WebSockets, Server-Sent Events, MQTT и Webhooks предоставляют возможности в режиме реального времени, обеспечивая бесперебойную связь между клиентом и сервером.
• Гибкость. Гибкость означает возможность адаптировать запросы и ответы к конкретным потребностям клиента. GraphQL выделяется в этом аспекте, позволяя клиентам точно запрашивать нужные им данные в одном запросе.

Выбор правильной архитектуры API

Выбор наиболее подходящей архитектуры API для вашего проекта включает в себя рассмотрение нескольких факторов:

1. Масштабируемость. Оцените требования к масштабируемости вашего приложения и выберите архитектуру, способную эффективно справляться с растущими нагрузками. Для сценариев с высоким спросом такие архитектуры, как gRPC, MQTT и AMQP, обеспечивают отличные возможности масштабирования.
2. Общение в реальном времени. Определите, является ли общение в реальном времени необходимым для вашего приложения. Если немедленные обновления и уведомления в режиме реального времени имеют решающее значение, рассмотрите такие архитектуры, как WebSockets, MQTT, Server-Sent Events или Webhooks.
3. Гибкость: оцените гибкость, необходимую для вашего API. Если вам требуются широкие возможности настройки запросов данных и ответов, мощные возможности запросов GraphQL могут быть правильным выбором.
4. Сложность. Учитывайте сложность архитектуры и наличие у вашей команды необходимого опыта. REST часто является простым выбором из-за его широкого распространения, в то время как архитектуры, такие как gRPC и AMQP, могут потребовать дополнительных усилий, чтобы понять их тонкости.

В зависимости от характера вашего приложения и его требований вы можете выбрать одну из следующих архитектур:

1. REST: идеально подходит для традиционных веб-приложений и общедоступных API благодаря своей простоте, масштабируемости и широкому распространению. Он лучше всего подходит для сценариев, где не требуется связь в реальном времени.
2. Веб-перехватчики. Подходит для сценариев, в которых важны асинхронные уведомления о событиях, например уведомления в реальном времени, интеграции и системы, управляемые событиями.
3. SOAP: обычно используется в корпоративных системах и устаревших интеграциях, обеспечивая высокий уровень контроля и обширную инструментальную поддержку. Однако работать с ним может быть сложно по сравнению с другими архитектурами.
4. GraphQL: хорошо подходит для клиентоориентированных приложений с гибкими требованиями к данным. Это позволяет клиентам запрашивать именно те данные, которые им нужны, уменьшая количество избыточной или недостаточной выборки данных.
5. WebSockets: идеально подходит для приложений реального времени, требующих двунаправленного обмена данными между клиентом и сервером, таких как системы чата или инструменты для совместной работы.
6. gRPC: предназначен для высокопроизводительного межсервисного взаимодействия в распределенных системах, особенно подходит для архитектур микросервисов.
7. MQTT. Легкий и эффективный протокол MQTT широко используется в сценариях Интернета вещей и телеметрии в реальном времени, где присутствуют ограничения пропускной способности и ресурсов.
8. AMQP: надежный протокол обмена сообщениями, подходящий для корпоративных сценариев обмена сообщениями и интеграции, обеспечивающий надежную связь и гибкость форматов данных.
9. Отправленные сервером события: полезны для доставки клиентам обновлений в реальном времени и push-уведомлений сервера, что делает его идеальным для прямых трансляций или приложений для мониторинга в реальном времени.
10. EDI: в основном используется для связи между компаниями (B2B), обеспечивая стандартизированный и автоматизированный обмен структурированными деловыми документами.
11. EDA: архитектурный шаблон, в котором особое внимание уделяется системам, управляемым событиями, обеспечивающим масштабируемость и разделение сервисов, что делает его подходящим для микросервисов и масштабируемых архитектур.

Примеры и рабочие процессы

Вот краткие примеры кода и рабочие процессы упомянутых архитектур API в Python:

ОТДЫХ

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/api/books', methods=['GET'])
def get_books():
    books = [
        {'title': 'Book 1', 'author': 'Author 1'},
        {'title': 'Book 2', 'author': 'Author 2'},
        {'title': 'Book 3', 'author': 'Author 3'}
    ]
    return jsonify(books)

if __name__ == '__main__':
    app.run()

1. Клиент делает запрос. Клиент инициирует HTTP-запрос к серверу, включая метод HTTP, конечную точку URL и любые необходимые данные.
2. Сервер получает запрос: сервер проверяет входящий запрос, включая метод HTTP, конечную точку URL и любые дополнительные данные.
3. Маршрутизация и сопоставление конечных точек: система маршрутизации сервера сопоставляет конечную точку URL с соответствующим обработчиком конечных точек в серверном приложении.
4. Выполнение обработчика конечной точки: сервер выполняет соответствующий код или функцию, связанную с конечной точкой.
5. Извлечение данных или манипулирование: сервер извлекает или манипулирует данными из баз данных или других источников, если это необходимо.
6. Сериализация и форматирование данных. Сервер преобразует данные ответа в структурированный формат, обычно JSON, XML или HTML.
7. Формирование ответа. Сервер создает ответ HTTP, который включает сериализованные данные, соответствующие коды состояния HTTP и все необходимые заголовки ответа.
8. Сервер отправляет ответ: сервер отправляет сформированный ответ обратно клиенту в виде ответа HTTP.
9. Клиент получает и обрабатывает ответ. Клиент получает ответ HTTP от сервера и обрабатывает данные, обрабатывает код состояния и выполняет соответствующие действия.

Вебхуки

from flask import Flask, request

app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def handle_webhook():
    data = request.get_json()
    # Process the data received from the webhook
    # ...
    return 'Webhook received'

if __name__ == '__main__':
    app.run()

1. Настройка и регистрация. Стороннее приложение или служба настраивает и регистрирует веб-перехватчик на сервере, предоставляя конечную точку URL-адреса, на которую сервер отправляет события.
2. Происхождение события. В системе сервера происходит событие, например создание нового заказа, регистрация пользователя или обработка платежа.
3. Уведомление о событии. Сервер отправляет HTTP-запрос POST на зарегистрированный URL-адрес веб-перехватчика, содержащий данные о событии и контекстную информацию.
4. Выполнение обработчика веб-перехватчика. Сервер клиента получает входящий запрос веб-перехватчика и выполняет обработчик веб-перехватчика, который обрабатывает событие и выполняет действия на основе типа события и связанных данных.
5. Обработка события. Внутри обработчика веб-перехватчика сервер клиента обрабатывает полученные данные о событии в соответствии со своей бизнес-логикой, например, обновляет внутренние базы данных, инициирует уведомления, инициирует рабочие процессы или выполняет желаемые действия на основе события. .
6. Ответ серверу: после обработки события клиентский сервер может отправить HTTP-ответ обратно на сервер, который активировал веб-перехватчик, чтобы указать, был ли веб-перехватчик успешно получен и обработан.

МЫЛО

from spyne import Application, rpc, ServiceBase, Iterable, Integer, Unicode
from spyne.protocol.soap import Soap11
from spyne.server.wsgi import WsgiApplication

# Define a SOAP service
class HelloWorldService(ServiceBase):
    
    @rpc(Unicode, Integer, _returns=Iterable(Unicode))
    def say_hello(self, name, times):
        for i in range(times):
            yield f"Hello, {name}! This is greeting number {i+1}"

# Create an instance of the SOAP application
soap_app = Application([HelloWorldService],
                       'http://localhost:8000/soap',
                       in_protocol=Soap11(validator='lxml'),
                       out_protocol=Soap11())

# Create a WSGI application to serve the SOAP application
wsgi_app = WsgiApplication(soap_app)

# Run the server
if __name__ == '__main__':
    from wsgiref.simple_server import make_server
    server = make_server('localhost', 8000, wsgi_app)
    server.serve_forever()

1. Описание службы. Поставщик службы SOAP публикует документ WSDL, в котором описываются доступные методы SOAP и их входные и выходные параметры. Клиент извлекает документ WSDL, чтобы понять структуру и функциональность службы SOAP.
2. Генерация клиентского кода. Используя документ WSDL, клиент генерирует клиентский код для взаимодействия со службой SOAP. Этот код создает классы и методы, соответствующие методам и структурам данных SOAP, определенным в WSDL.
3. Связь клиент-сервер. Клиент отправляет запрос SOAP на конечную точку службы SOAP по сетевому протоколу, такому как HTTP или SMTP.
4. Обработка запроса. Служба SOAP получает входящий запрос, извлекает сообщение SOAP и идентифицирует запрошенный метод и параметры SOAP.
5. Выполнение метода: сервер выполняет необходимые действия на основе предоставленных входных параметров, таких как извлечение данных или выполнение бизнес-логики.
6. Генерация ответа: после выполнения метода сервер генерирует ответ SOAP, который включает результат выполнения метода или любые сообщения об ошибках.
7. Передача ответа. Ответ SOAP отправляется обратно клиенту по сетевому протоколу.
8. Обработка ответа. Клиент получает ответ SOAP и извлекает соответствующую информацию на основе структуры, определенной в WSDL.
9. Интеграция клиентского приложения. Клиентское приложение обрабатывает данные ответа и предпринимает соответствующие действия в зависимости от результата, например, отображает данные пользователю или обновляет локальные базы данных.

ГрафQL

from flask import Flask, jsonify, request
from graphene import ObjectType, String, Schema

# Define a GraphQL schema
class Query(ObjectType):
    hello = String()

    def resolve_hello(self, info):
        return 'Hello, world!'

# Create a Flask app
app = Flask(__name__)

# Define the GraphQL endpoint
@app.route('/graphql', methods=['POST'])
def graphql():
    # Get the GraphQL query from the request
    query = request.get_json().get('query')

    # Execute the query against the schema
    result = Schema(query=Query).execute(query)

    # Return the result as JSON
    return jsonify(result.to_dict())

# Run the Flask app
if __name__ == '__main__':
    app.run()

1. Клиент отправляет запрос GraphQL. Клиент отправляет запрос на сервер, указывая поля и взаимосвязи необходимых ему данных.
2. Передача запроса: клиент отправляет запрос на конечную точку сервера GraphQL (/graphql) с помощью запроса POST.
3. Синтаксический анализ и проверка запроса. Сервер анализирует и проверяет запрос на соответствие определенной схеме.
4. Выполнение запроса. Сервер определяет функции преобразователя, соответствующие запрошенным полям в запросе, и извлекает данные из базовых источников.
5. Извлечение и преобразование данных. Функции преобразователя извлекают запрошенные данные из источников и преобразовывают их в соответствующие типы GraphQL.
6. Конструкция ответа данных. Сервер собирает полученные данные в объект ответа, соответствующий структуре запроса.
7. Передача ответа. Сервер отправляет ответ обратно клиенту в виде HTTP-ответа в формате JSON.
8. Обработка ответа. Клиент обрабатывает ответ, извлекая и используя запрошенные данные.

Веб-сокеты

import asyncio
import websockets

# Define the WebSocket server handler
async def server(websocket, path):
    # Continuously receive and handle messages from the client
    async for message in websocket:
        # Process the received message
        print(f"Received message: {message}")

        # Send a response back to the client
        response = f"Received: {message}"
        await websocket.send(response)

# Start the WebSocket server
start_server = websockets.serve(server, "localhost", 8765)

# Run the event loop to start accepting client connections
asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

1. Инициализация сервера. Сервер настраивает сервер WebSocket с помощью библиотеки или платформы WebSocket, например websockets в Python.
2. Подключение клиента. Клиент подключается к серверу, отправляя запрос установления связи WebSocket. Сервер проверяет запрос и в случае успеха устанавливает соединение WebSocket с клиентом.
3. Обновление WebSocket: после установления соединения WebSocket базовое HTTP-соединение обновляется до протокола WebSocket.
4. Двунаправленная связь. При установленном соединении WebSocket и клиент, и сервер могут отправлять и получать сообщения в режиме реального времени. Сообщения могут быть отправлены в виде текста или двоичных данных.
5. Рабочий процесс, основанный на событиях. В серверных и клиентских приложениях реализованы рабочие процессы, управляемые событиями, для обработки событий WebSocket.
6. Обработка сообщений. При получении сообщения от клиента или сервера запускается соответствующий обработчик событий. Приложение обрабатывает сообщение и при необходимости формирует ответ.
7. Обновления в реальном времени. Соединение WebSocket позволяет получать обновления и уведомления в режиме реального времени от сервера к подключенным клиентам.
8. Завершение соединения: соединение WebSocket остается открытым до тех пор, пока либо сервер, либо клиент не решит закрыть соединение.

gRPC

Определите службу gRPC:

syntax = "proto3";

package example;
service GreetingService {
  rpc SayHello (HelloRequest) returns (HelloResponse) {}
}

message HelloRequest {
  string name = 1;
}

message HelloResponse {
  string message = 1;
}

Сгенерируйте код gRPC:

$ python -m grpc_tools.protoc -I . --python_out=. --grpc_python_out=. example.proto

Внедрите сервер gRPC:

import grpc
from concurrent import futures
import example_pb2
import example_pb2_grpc

class GreetingServicer(example_pb2_grpc.GreetingServiceServicer):
    def SayHello(self, request, context):
        message = f"Hello, {request.name}!"
        return example_pb2.HelloResponse(message=message)

server = grpc.server(futures.ThreadPoolExecutor())
example_pb2_grpc.add_GreetingServiceServicer_to_server(GreetingServicer(), server)
server.add_insecure_port('[::]:50051')
server.start()
server.wait_for_termination()

Внедрите клиент gRPC:

import grpc
import example_pb2
import example_pb2_grpc

channel = grpc.insecure_channel('localhost:50051')
stub = example_pb2_grpc.GreetingServiceStub(channel)

request = example_pb2.HelloRequest(name='Alice')
response = stub.SayHello(request)
print(response.message)

1. Определение службы. Поставщик услуг определяет службу gRPC и типы сообщений с помощью протокольных буферов (protobuf).
2. Компиляция службы. Файл определения службы компилируется для создания кода для конкретного языка, включая серверные и клиентские заглушки, а также логику сериализации и десериализации для типов сообщений.
3. Настройка сервера. Сервер gRPC инициализирует и настраивает экземпляр сервера, привязывается к определенному сетевому адресу и порту, загружает сгенерированные заглушки сервера и реализует бизнес-логику для обработки клиентских запросов.
4. Подключение клиента. Клиент gRPC устанавливает соединение с сервером, создает канал gRPC и инициализирует созданные клиентские заглушки, связанные со службой gRPC.
5. Поток запросов и ответов: клиентское приложение создает сообщение запроса и вызывает соответствующий удаленный метод на клиентской заглушке, передавая сообщение запроса в качестве параметра. Затем платформа gRPC отправляет сериализованное сообщение запроса на сервер по сети.
6. Обработка на стороне сервера. Сервер gRPC получает сообщение запроса, десериализует его, выполняет бизнес-логику, связанную с запрошенным методом, и потенциально получает доступ к базам данных, внешним службам или выполняет вычисления.
7. Генерация ответа. После обработки запроса сервер создает ответное сообщение и возвращает его в структуру gRPC.
8. Доставка ответа. Платформа gRPC сериализует ответное сообщение в двоичный формат и отправляет его по сети клиентскому приложению.
9. Обработка на стороне клиента. Клиент gRPC получает двоичный ответ, десериализует его и обращается к ответному сообщению.
10. Разрыв соединения: после завершения связи клиент или сервер могут закрыть соединение.

MQTT

Издатель MQTT:

import paho.mqtt.client as mqtt

# Define callback functions
def on_connect(client, userdata, flags, rc):
    print("Connected with result code " + str(rc))
    client.publish("topic/test", "Hello, MQTT!")

def on_publish(client, userdata, mid):
    print("Message published")

# Create an MQTT client
client = mqtt.Client()

# Set callback functions
client.on_connect = on_connect
client.on_publish = on_publish

# Connect to the MQTT broker
client.connect("broker.example.com", 1883, 60)

# Start the MQTT loop
client.loop_start()

# Publish a message
client.publish("topic/test", "Hello, MQTT!")

# Disconnect from the broker
client.disconnect()

MQTT-подписчик:

import paho.mqtt.client as mqtt

# Define callback functions
def on_connect(client, userdata, flags, rc):
    print("Connected with result code " + str(rc))
    client.subscribe("topic/test")

def on_message(client, userdata, msg):
    print("Received message: " + str(msg.payload))

# Create an MQTT client
client = mqtt.Client()

# Set callback functions
client.on_connect = on_connect
client.on_message = on_message

# Connect to the MQTT broker
client.connect("broker.example.com", 1883, 60)

# Start the MQTT loop
client.loop_forever()

1. Настройка брокера. Брокер MQTT устанавливается на сервере, который действует как центральный брокер сообщений. Он прослушивает входящие соединения MQTT от клиентов и обрабатывает рассылку сообщений.
2. Рабочий процесс издателя (клиента). Клиент издателя устанавливает соединение с брокером MQTT и публикует сообщения в определенных темах, содержащих полезную нагрузку. Затем брокер распределяет сообщения среди подписанных клиентов.
3. Рабочий процесс подписчика (клиента): клиент-подписчик устанавливает соединение с брокером MQTT и подписывается на одну или несколько тем. Брокер пересылает опубликованные сообщения клиенту-подписчику.
4. Рассылка сообщений. Когда клиент-издатель отправляет брокеру сообщение с определенной темой, брокер пересылает сообщение всем клиентам, подписавшимся на эту тему. Подписанные клиенты получают сообщение и могут его обработать.
5. Качество обслуживания (QoS): MQTT поддерживает различные уровни качества обслуживания для обеспечения надежной доставки сообщений. QoS 0: Доставка не более одного раза. QoS 1: хотя бы одна доставка. QoS 2: Доставка ровно один раз.
6. Взаимодействие клиент-сервер: клиенты MQTT (издатели и подписчики) взаимодействуют с брокером MQTT. Брокер управляет клиентскими подключениями и распространением сообщений.

AMQP

Производитель AMQP (издатель):

import pika

# Create a connection to the RabbitMQ server
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Declare a queue
channel.queue_declare(queue='my_queue')

# Publish a message to the queue
channel.basic_publish(exchange='', routing_key='my_queue', body='Hello, AMQP!')

# Close the connection
connection.close()

Потребитель AMQP (подписчик):

import pika

# Callback function for receiving messages
def callback(ch, method, properties, body):
    print("Received message:", body)

# Create a connection to the RabbitMQ server
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Declare a queue
channel.queue_declare(queue='my_queue')

# Set the callback function to receive messages from the queue
channel.basic_consume(queue='my_queue', on_message_callback=callback, auto_ack=True)

# Start consuming messages
channel.start_consuming()

1. Настройка брокера. Брокер AMQP устанавливается и работает на сервере. Он прослушивает входящие соединения и управляет очередью, маршрутизацией и доставкой сообщений.
2. Рабочий процесс производителя (клиента): клиент-производитель устанавливает соединение с брокером, создает канал, объявляет необходимые обмены и очереди и отправляет сообщения в определенные обмены или очереди.
3. Рабочий процесс потребителя (клиента): клиент-потребитель устанавливает соединение с брокером, создает канал, объявляет необходимые обмены и очереди и начинает потреблять сообщения из указанных очередей.
4. Маршрутизация сообщений и типы обмена: обмен сообщениями маршрутизируется в очереди на основе предопределенных правил. Различные типы обмена определяют способ маршрутизации сообщений. Производители публикуют сообщения на определенных биржах, а потребители привязывают свои очереди к нужным биржам.
5. Очереди и доставка сообщений. Очереди удерживают сообщения до тех пор, пока они не будут использованы клиентами. Потребители привязывают свои очереди к биржам для получения сообщений, соответствующих определенным критериям маршрутизации. Обмен доставляет сообщение в соответствующие очереди.
6. Качество обслуживания (QoS): AMQP поддерживает различные уровни QoS для обеспечения надежной доставки сообщений. Более высокие уровни QoS обеспечивают более надежные гарантии, но могут повлиять на производительность.
7. Взаимодействие клиент-сервер: производители публикуют сообщения в определенных обменах или очередях. Потребители потребляют сообщения из нужных очередей. Брокер обрабатывает маршрутизацию и доставку сообщений между производителями и потребителями.

События, отправленные сервером

from flask import Flask, Response

app = Flask(__name__)

# Route that streams SSE events to the client
@app.route('/stream')
def stream():
    def event_stream():
        # Generate and yield events to the client
        yield 'data: Hello, SSE!\\n\\n'
        yield 'data: This is a server-sent event.\\n\\n'
        yield 'data: You can send real-time updates to the client.\\n\\n'
    
    # Create a response with the event stream content type
    return Response(event_stream(), mimetype='text/event-stream')

if __name__ == '__main__':
    app.run()

1. Соединение клиент-сервер. Клиент отправляет HTTP-запрос GET на конечную точку SSE, чтобы установить соединение с сервером. Сервер отвечает необходимыми заголовками, чтобы указать, что он будет отправлять события SSE.
2. Протокол событий, отправленных сервером (SSE). Сервер отправляет события SSE клиенту, используя протокол SSE, который определяет формат и структуру событий.
3. Формат потока событий. События SSE отправляются в виде обычного текста по HTTP-соединению, при этом каждое событие представляется в виде отдельного сообщения. Сообщения имеют определенный формат с предопределенными полями, такими как event, data, id и retry.
4. Генерация событий на стороне сервера. Сервер генерирует события на основе логики приложения или обновлений данных, которые затем асинхронно передаются клиенту.
5. Потоковая передача событий. Сервер передает клиенту потоки событий SSE, при этом каждое событие отправляется в виде отдельного сообщения с соответствующим форматированием.
6. Обработка событий на стороне клиента. Код JavaScript на стороне клиента использует EventSource API для обработки входящих событий SSE, доступа к данным событий и выполнения таких действий, как обновление пользовательского интерфейса, отображение уведомлений в реальном времени, или запуск определенных функций.
7. Непрерывное соединение. Соединение SSE остается открытым между клиентом и сервером, что позволяет обмениваться данными и обновлениями в режиме реального времени без необходимости явных запросов.

ЭОД

import pyx12

# Read and parse an EDI file
edi_data = open('edi_file.edi', 'r').read()
parsed_data = pyx12.x12n_document.ParsedDocument()
parsed_data.set_grammar("837")
parsed_data.load(edi_data)

# Extract and process the data from the EDI file
for segment in parsed_data.iter_segments():
    segment_id = segment.get_seg_id()
    segment_data = segment.get_data_elements()
    
    # Process the segment data as needed
    # ...

# Generate an EDI file
edi_generator = pyx12.x12file.X12File('837')
edi_generator.write('ST*837*0001')
edi_generator.write('BHT*0010*00*0000000001*20001231*1159*CH')
edi_generator.write('...')  # Write additional segments
edi_generator.write('SE*3*0001')
edi_generator.write('GE*1*1')
edi_generator.write('IEA*1*000000001')
edi_generator.close()

1. Соглашение с торговым партнером: партнеры согласовывают детали обмена деловыми документами с использованием стандартов EDI, включая типы сообщений, протоколы связи, форматы данных и меры безопасности.
2. Генерация сообщения: клиент подготавливает бизнес-данные в форме сообщения EDI на основе согласованного стандарта EDI и типа сообщения.
3. Передача: отправитель передает сообщение EDI в систему получателя, используя различные методы связи.
4. Преобразование и проверка данных. Система получателя получает и преобразует сообщение EDI, выполняя проверки для обеспечения целостности и соответствия данных.
5. Бэкэнд-обработка. Бэкэнд-системы сервера обрабатывают данные после успешного перевода и проверки.
6. Генерация ответа: сервер может генерировать ответ в форме подтверждения EDI или другого сообщения EDI после обработки данных.
7. Обработка ошибок. Обе системы обрабатывают сценарии ошибок в соответствии с согласованными протоколами, которые могут включать в себя отправку подтверждений ошибок, повторную передачу сообщений или взаимодействие для решения проблем.

ЭДА

from event_bus import EventBus

# Define event handlers
def event_handler1(event):
    print(f"Event Handler 1 received event: {event}")

def event_handler2(event):
    print(f"Event Handler 2 received event: {event}")

# Initialize event bus
event_bus = EventBus()

# Subscribe event handlers to events
event_bus.subscribe("event_type1", event_handler1)
event_bus.subscribe("event_type2", event_handler2)

# Publish events
event_bus.publish("event_type1", {"key": "value"})
event_bus.publish("event_type2", {"key": "value"})

# Unsubscribe event handlers
event_bus.unsubscribe("event_type1", event_handler1)
event_bus.unsubscribe("event_type2", event_handler2)

1. Генерация событий. Клиент или внешние системы генерируют события на основе определенных триггеров или действий.
2. Публикация событий. Клиент публикует события в шине событий или потоковой платформе, выступая в качестве центрального канала связи.
3. Маршрутизация и фильтрация событий. Шина событий направляет события к компонентам на стороне сервера на основе предопределенных правил или подписок, фильтруя их по релевантности.
4. Обработка событий. Обработчики событий получают события из шины событий и обрабатывают их с помощью определенной бизнес-логики или функций, таких как обновление баз данных или вызов служб.
5. Ответ со стороны сервера. После обработки событий серверные компоненты могут генерировать ответы или инициировать дополнительные события. Их можно опубликовать обратно в шину событий.
6. Реакция на стороне клиента: клиентский компонент получает ответы или события от шины событий, реагируя на них, обновляя свой пользовательский интерфейс, отображая уведомления или выполняя другие действия.

Заключение

Выбор правильной архитектуры API имеет решающее значение для создания успешных и масштабируемых приложений. Чтобы принять взвешенное решение, необходимо понимать ключевые характеристики различных архитектур и учитывать такие факторы, как масштабируемость, обмен данными в режиме реального времени, гибкость и сложность. Не забудьте оценить требования вашего проекта и выбрать архитектуру, которая наилучшим образом соответствует вашим потребностям.

Выбор архитектуры API должен определяться конкретными потребностями вашего приложения, желаемыми шаблонами связи и ожидаемыми требованиями к масштабируемости и гибкости. Независимо от того, создаете ли вы простое веб-приложение, систему обмена сообщениями в реальном времени или распределенное корпоративное решение для интеграции, внимательно оцените доступные варианты и выберите архитектуру API, которая наилучшим образом соответствует вашим целям и требованиям.

Спасибо за чтение и счастливого творчества!

Спасибо за чтение и удачного творчества!

Я надеюсь, что эта статья была полезной для вас. Спасибо, что нашли время, чтобы прочитать его.

Чтобы не пропустить вдохновение, ознакомьтесь с другими моими статьями. Продолжаем учиться и развиваться вместе!

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .