#rest #soap
Споры об этих способах интеграции не утихнут никогда. Знакомить с сутью этих способов здесь не будем. Об этом написано немало. Поговорим о том, в каких случаях лучше применять Rest, а в каких soap. Позже мы подробно разберём некоторые аспекты

Ориентированность
REST ориентирован на доступ к ресурсам. Является простым интерфейсом управления информацией (сущностями) без дополнительных прослоек (конверты, xml и пр.). Основным потребителем считаются люди. Пример: создать новый счет у клиента, удалить шаблон автоплатежа
SOAP - на исполнение удалённых сервисов. Полезен для выполнения транзакций (операций). Основным потребителем считаются компьютеры. Пример: подтвердить снятие средств, перевести средства


Форматы
REST поддерживает xml и json
SOAP работает только с xml

Протоколы
SOAP может использоваться с протоколами SMTP, FTP, HTTP, HTTPS
Rest обычно HTTP и HTTPS


Хранение состояний
Rest - Stateless
Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для выполнения этого запроса, без хранения какого-либо контекста на стороне сервера. Состояние сеанса целиком хранится на стороне клиента.

SOAP - Stateful. Состояние клиента может храниться на сервере, что означает необязательность передачу состояния клиента при каждом запросе с клиента. это протокол без сохранения состояния, но разработчик может встроить в заголовок механизмы управления сеансом, чтобы встроить состояние в транзакцию


Использование ресурсов
REST «ест» меньше ресурсов, чем SOAP.
Он менее ресурсоемкий, потому что отсутствуют доп.слои и не нужно тратить время на парсинг запроса, чтобы понять, что именно нужно сделать в запросе. Кроме того, REST легко масштабируется. Благодаря своей производительность REST реализовывают в случае интенсивно используемых API (Google, Яндекс и пр)

У SOAP объемные сообщения (даже пустой envelope занимает 158 байт. Это не много, но больше, чем пустой json), но тк SOAP аккумулирует в себе целый пакет WS-стандартов, то в него заложено больше возможностей, о которых поговорим позже.

Слои
SOAP: необходим wsdl- документ, который описывает методы, доступные клиенту для вызова. Сложность в том, что клиенту необходимо создать обертки для каждого метода, которые он будет вызывать у выбранного сервиса. И неправильное обновление описания веб-сервиса может привести к поломке клиента.
REST: интерфейс всегда один: CRUD. Преимущество данном стиля в том, что этот интерфейс гладко ложится на методы протокола http. А сущности идентифицируются при помощи URI.

#rest #soap
Поговорим об областях применения REST и SOAP.

🔸Где хорош SOAP
SOAP позволяет передавать данные в децентрализованной, распределенной среде. Он также имеет множество механизмов веб-безопасности. Эти качества делают его идеальным для корпоративных решений.
Сервер хранит информацию о клиенте и использует ее в серии запросов или цепочке операций. Хотя это требует больше ресурсов сервера и пропускной способности, это важно при выполнении повторяющихся или цепных задач, например, банковских переводов.
SOAP не зависит от базового транспортного протокола, поэтому не обязательно использовать HTTP. Вместо этого можно использовать SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) или другой транспортный протокол, в зависимости от приложения.

🔹Где хорош REST
В REST отсутствуют некоторые встроенные функции безопасности, которые есть в SOAP – но они и не нужны при работе с публичными данными и сервисами.
Все вызовы REST API должны быть без статических данных, тк этот подход stateless. Это означает, что каждое взаимодействие является независимым, поэтому каждый запрос и ответ содержат всю информацию, необходимую для завершения взаимодействия. Поскольку сервер воспринимает каждый запрос как новый, он не хранит информацию о прошлых запросах. Это значительно сокращает объем необходимой памяти сервера.
Это повышает производительность, так как серверу не нужно предпринимать дополнительные действия или получать прошлые данные при выполнении запроса. Поскольку REST не имеет статического характера, данные можно кэшировать, что также экономит ресурсы сервера и пропускную способность. Наконец, API REST могут использовать различные форматы данных, например, JSON, который легче XML. Это делает их более быстрыми и эффективными, чем большинство SOAP API.

📚Итого

🟠SOAP лучше применять:
✔️для больших и сложных структур данных
✔️для выполнения операций
для случаев, где необходимо хранить состояние (корзина покупателя в интернет-магазине)
✔️Где важна Конфиденциальность и безопасность передаваемых данных

🟣Где хорош REST:
✔️Где производятся стандартные CRUD-операции с данными

Привет! Меня зовут Борисова Дарья. Я работаю в сфере IT уже больше восьми лет, и этот путь начался еще на первом курсе университета — я инженер-программист по образованию.

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

За эти годы я накопила огромный багаж знаний, которым теперь хочу делиться с вами. Если вам интересно развиваться в направлении архитектуры, если вас увлекают проектирование сложных систем и интеграция, то добро пожаловать в мой блог! Здесь мы будем говорить о современных подходах, лучших практиках и новых идеях в мире IT.

Обычный сервер VS веб-сервер
#web #сервер

Многие путают понятия обычного сервера приложений и веб-сервера. Давайте разберёмся, кто есть кто.

Веб-сервер

Веб-сервер — это специализированный сервер, который занимается доставкой веб-страниц через Интернет. Основная функция веб-сервера — принимать запросы от браузеров клиентов и отправлять обратно контент, такой как HTML-документы, CSS-стили, изображения и JavaScript-файлы. Для этой цели веб-сервер использует протокол HTTP (HyperText Transfer Protocol), который управляет передачей данных между клиентом и сервером.

Когда пользователь вводит адрес сайта в браузер, происходит следующее:
1. Браузер отправляет HTTP-запрос на веб-сервер.
2. Веб-сервер находит нужный файл (например, страницу) и возвращает его клиенту.
3. Браузер отображает полученную страницу.

Таким образом, веб-сервер играет роль посредника между пользователем и сайтом.

Сервер приложений

Сервер приложений — это более сложная система, чем веб-сервер. Она предназначена для выполнения программ, сценариев и процедур, необходимых для работы различных приложений. В отличие от веб-сервера, сервер приложений работает не только с веб-контентом, но и с корпоративными приложениями, которые требуют сложной бизнес-логики.

Сервер приложений часто включает в себя встроенный веб-сервер, но обладает дополнительными функциями, такими как:
- Поддержка многопоточности и распределённых транзакций.
- Управление базами данных и пулами соединений.
- Балансировка нагрузки и отказоустойчивость.

Основные отличия

- Тип контента: веб-сервер лучше подходит для статичного контента (HTML-страницы, изображения), тогда как сервер приложений нужен для динамичного контента, когда данные генерируются в режиме реального времени.
- Поддерживаемые технологии: веб-сервер поддерживает скрипты вроде PHP, ASP или JSP, а сервер приложений дополнительно работает с уровнями приложений, такими как управление объектами, транзакциями и сообщениями.
- Масштабируемость: сервер приложений способен обрабатывать большие объёмы трафика благодаря поддержке многопоточности и кластеризации.

Заключение

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

Для организации асинхронной связи между сервисами часто применяются менеджеры очередей и брокеры сообщений. На интервью я нередко задаю вопрос аналитикам о различиях между этими механизмами. К сожалению, лишь 20% кандидатов дают правильный ответ. Ещё 20% пытаются ответить, но ошибаются, а оставшиеся 60% честно признаются, что не знают.
⚡️ Пора прояснить, какие функции выполняют эти компоненты.

📌 Очередь
Очередь — это метод обработки сообщений в асинхронном режиме. Она служит временным хранилищем для сообщений. Один компонент, который называется производителем (Producer), отправляет сообщение в очередь, где оно сохраняется до тех пор, пока другой компонент — потребитель (Consumer) — не извлечёт его и не обработает.
Одна очередь может использоваться несколькими производителями и потребителями одновременно. Для координации поступления и выбытия сообщений из очереди используется специальная система — брокер.

📌 Брокер
Брокер сообщений (Message Broker) собирает и направляет сообщения согласно заранее определённой логике. Каждое сообщение может сопровождаться специальным ключом, на основании которого брокер определяет, в какую очередь или очереди его нужно отправить.

❓ Хотите узнать подробнее про каждого из них?

💈Брокер сообщений: ключевые функции и преимущества
Рассмотрим подробнее брокер сообщений. Он играет роль посредника между производителем и потребителем, обеспечивая независимую и эффективную передачу сообщений. Его главная задача заключается в поддержке логической структуры, позволяющей создавать и обрабатывать сообщения.

🔅Асинхронность
Брокер поддерживает асинхронный обмен данными между участниками системы. Производитель может отправлять сообщения вне зависимости от готовности потребителя, и наоборот. Это делает коммуникацию гибкой и эффективной.

🔅Масштабирование
Система легко адаптируется под увеличение нагрузки благодаря возможности добавления новых потребителей на разные серверы. Их количество можно изменять динамически, обеспечивая эластичность системы. При этом производитель продолжает функционировать без изменений конфигурации.

🔅Надежность передачи
Одним из ключевых преимуществ брокера является обеспечение надежной доставки сообщений. Даже в случае кратковременного разрыва соединения между производителем и потребителем, сообщения сохраняются и доставляются после восстановления связи. Таким образом, ни один элемент данных не теряется.

🔅Повышенная отказоустойчивость
Брокер также повышает устойчивость всей системы. Если один из потребителей выходит из строя во время обработки сообщения, другое устройство может взять на себя эту задачу. Благодаря механизму сохранения сообщений в очереди, повторная обработка становится возможной.

🔅Универсальность и совместимость
Брокер работает исключительно как маршрутизатор, не анализируя содержимое сообщений. Это позволяет различным компонентам системы взаимодействовать, даже если они написаны на разных языках программирования или работают на различных платформах.

🔅Балансировка нагрузки
Вы знали, что брокер зачастую выполняет функцию балансировки нагрузки между сервисами и очередями? причем, он распределяет запросы равномерно и эффективно.

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

Таким образом, брокер сообщений представляет собой мощный инструмент для обеспечения эффективного, надежного и безопасного взаимодействия между различными элементами сложной распределенной системы.

📣Расскажите, какими брокерами пользуетесь и часто ли они участвуют в ваших интеграциях?

При выборе брокера сообщений важно учитывать несколько ключевых критериев, которые помогут обеспечить эффективную и надежную работу системы.
💾 Сохраняйте, чтобы не забыть!

Основные критерии выбора брокера сообщений

🟣 Масштабируемость: Способность брокера поддерживать увеличение нагрузки без потери производительности. Это особенно важно для систем с высокой нагрузкой или динамическим ростом числа пользователей.

🟣 Надежность: Брокер должен обеспечивать гарантированную доставку сообщений, даже в случае сбоев или временных отключений. Это может включать механизмы подтверждения получения, повторной отправки и блокировки сообщений.

🟣 Производительность: Скорость обработки сообщений и способность брокера справляться с большим количеством сообщений в единицу времени. Это критично для систем, требующих низкой задержки и высокой пропускной способности.

🟣 Поддержка различных протоколов: Возможность работы с разными протоколами обмена сообщениями, такими как AMQP, MQTT, STOMP и другими. Это обеспечивает совместимость с различными приложениями и устройствами.

🟣 Безопасность: Наличие механизмов аутентификации, авторизации и шифрования данных. Это важно для защиты конфиденциальной информации и предотвращения несанкционированного доступа.

🟣 Отказоустойчивость: Способность брокера продолжать работу в случае выхода из строя отдельных компонентов или узлов. Это может включать кластеризацию, репликацию данных и автоматическое восстановление после сбоев.

🟣 Поддержка различных типов очередей: Возможность работы с различными типами очередей, такими как FIFO (первым пришел — первым вышел), приоритетные очереди и другие. Это позволяет гибко настраивать обработку сообщений в зависимости от требований системы.

🟣 Интеграция с другими системами: Легкость интеграции с существующими системами и инфраструктурами. Это может включать поддержку различных API, инструментов мониторинга и управления. А также возможность интеграции с различными языками программирования и фреймворками.

🟣 Поддержка кластеризации: Возможность создания кластеров брокеров для повышения отказоустойчивости и масштабируемости.

🟣 Поддержка ретрансляции сообщений: Возможность ретрансляции сообщений в случае сбоя или временного отключения потребителей.

🟣 Поддержка разных топологий: Возможность работы с различными топологиями обмена сообщениями, такими как точка-точка, публикация-подписка и другие.

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

🟣 Поддержка геораспределенных систем: Возможность работы в распределенных системах, где компоненты находятся в разных географических локациях.

Эти критерии помогут выбрать брокер сообщений, который наилучшим образом соответствует требованиям вашей системы

#мемдня
Сосредоточен на проблемах - это когда ты продумал все варианты ответа твоего метода, но забыл про 200...

А вы знали, что скоро я поделюсь своим опытом на конференции, посвященной моему любимому System Design. Наконец, я нашла единомышленников!
Подключайтесь!

🛰 Дарья Борисова, Системный аналитик с более чем 7-летним опытом в IT, выступит на третьей конференции Systems Design Online с докладом на тему «Подходы к оптимальному проектированию REST API»

План доклада:
1. Оптимизация кол-ва запросов
— Зачем оптимизировать запросы к серверу
— Как оптимизировать кол-во запросов?
— Детальное рассмотрение способа комбинирования API-эндпоинтов

2. Выбор стороны для проведения расчетов
— Когда лучше проводить расчеты на клиенте, а когда на сервере?
— Возможные компромиссы между производительностью и безопасностью

3. Пакетная обработка
— Понятие пакетной обработки
— Применение batch-запросов для оптимизации взаимодействия с API
— Ограничения и возможные риски при использовании этого подхода

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Гарантированная доставка и ретрансляция сообщений
Я вплотную работаю с банковскими системами, которые нужно интегрировать между собой, и иногда сталкиваюсь с проблемами потери данных или задержки их обработки. И такие проблемы могут привести к серьезным финансовым и репутационным рискам, поэтому рассмотрю эти аспекты подробнее.

📑 Что это?
➰ Гарантированная доставка: Сообщение должно быть доставлено хотя бы один раз. Это означает, что даже в случае сбоя системы, сообщение не будет потеряно и будет повторно отправлено до тех пор, пока не будет успешно доставлено.

➰Ретрансляция сообщений: Если сообщение не было успешно обработано, оно должно быть возвращено в очередь для повторной обработки. Это может произойти в случае временного сбоя в работе потребителя или ошибки в обработке.

📪 Механизмы настройки подтверждения получения (ACK):
🧷 Producer ACK: Производитель сообщений должен получить подтверждение от брокера о том, что сообщение было успешно принято. Это гарантирует, что сообщение не будет потеряно в случае сбоя на стороне производителя.
🧷 Consumer ACK: Потребитель сообщений должен отправить подтверждение брокеру после успешной обработки сообщения. Если подтверждение не получено, сообщение остается в очереди и может быть повторно отправлено.

🛎 Механизмы ретрансляции
➿Dead Letter Queue (DLQ): В случае сбоя при обработке сообщения, оно может быть перемещено в специальную очередь (DLQ), где оно будет храниться до тех пор, пока не будет обработано вручную или повторно отправлено.
➿Retry Mechanism: Настройка количества попыток повторной отправки сообщения перед его перемещением в DLQ. Это позволяет избежать бесконечных циклов повторной обработки и потери сообщений.

📌 Какие брокеры рекомендую:
Apache Kafka – самый популярный брокер
RabbitMQ - Поддерживает различные модели обмена сообщениями и обеспечивает высокую надежность и отказоустойчивость.
IBM MQ - Популярен в корпоративной среде благодаря своей надежности и безопасности, но я его не оценила

Брокеры подробно рассмотрели, теперь пришло время для очередей сообщений. Очередь – это промежуточный буфер, где сообщения временно хранятся до тех пор, пока получатель не сможет их обработать.

Основные аспекты работы очередей сообщений

♨️Поддержка методов получения сообщений
Push-метод: В данном случае отправитель сам отправляет сообщение в очередь, а получатели получают уведомления о наличии новых сообщений. Это удобно, когда потребители готовы сразу же обрабатывать новые сообщения.
Pull-метод: Получатели сами периодически проверяют наличие новых сообщений в очереди и извлекают их оттуда. Этот метод подходит для сценариев, когда система должна поддерживать баланс нагрузки или имеет ограничения по ресурсам.

♨️Слабая связность компонентов
Наверное, это самый важный аспект для микросервисов. Благодаря использованию очередей, компоненты системы становятся слабо связанными друг с другом. Они взаимодействуют только через интерфейс очереди, а не напрямую. Это делает систему более гибкой и устойчивой к изменениям, так как каждый компонент может развиваться независимо от других.

♨️Масштабируемость
Добавление новых экземпляров потребителей позволяет легко масштабировать систему. Если нагрузка увеличивается, можно добавить дополнительные экземпляры, которые будут параллельно обрабатывать сообщения из одной и той же очереди. Таким образом, производительность системы улучшается без изменения архитектуры отдельных сервисов.

♨️ Гарантированная доставка
О ней мы подробно поговорили ранее, но повторим, что сообщение сохраняется в очереди до тех пор, пока оно не будет успешно обработано. Это обеспечивает надёжность передачи данных даже в условиях временных сбоев или ошибок.

♨️ Отказоустойчивость
Даже если один из сервисов выходит из строя, остальные продолжают функционировать благодаря буферизации сообщений в очереди. Когда неисправный сервис восстанавливается, он может продолжить обработку накопившихся сообщений.

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

Можно ли использовать очередь как временное хранилище?

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

🔑 Способ реализации

1️⃣ Настройка очереди
Создаем очередь сообщений, используя любой подходящий инструмент, будь то RabbitMQ, Kafka, AWS SQS или другой брокер сообщений. Важно выбрать правильную конфигурацию очереди, учитывая параметры её размера, времени жизни сообщений и политики повтора попыток обработки. Мы выбрали RabbitMQ.

2️⃣ Отправка сообщений
Срабатывает триггер на старт процесса (получение сообщения извне/ по таймеру и тд), появляются данные, требующие сохранения, и приложение формирует сообщение и отправляет его в очередь. Каждое сообщение содержит данные, необходимые для выполнения задачи позже.

3️⃣ Получение сообщений
Это же приложение подходит к этапу, когда ему нужно воспользоваться сохраненными данными. Для этого вычитывания данных в этом же приложении выделается отдельный поток/процесс, который забирает сообщение из очереди.
Если сообщение успешно обработано и интеграционный поток находится на финальной стадии, сообщение удаляется из очереди.
Если возникает ошибка, сообщение может быть возвращено обратно в очередь для повторной попытки обработки.

4️⃣ Дополнительные настройки
Можно установить время жизни для каждого сообщения в очереди. По истечении этого времени сообщение удаляется автоматически, если оно не было обработано вовремя. Это помогает избежать накопления устаревших данных.
А оповещения и мониторинг помогут отслеживать состояние очереди и оперативно реагировать на ошибки, например, если число неподтвержденных сообщений превысит допустимый порог.

✅ Преимущества подхода
🌀 Упорядоченность: Данные сохраняются в строго определенном порядке (FIFO), что полезно для последовательной обработки.
🌀Надежность: Сообщения сохраняются в очереди до тех пор, пока они не будут обработаны. Если происходит сбой в процессе обработки, сообщение остается доступным для повторной попытки.
🌀Масштабируемость: Система может добавлять или удалять процессы обработки сообщений динамически, улучшая масштабируемость.

‼️Недостатки
🔻Дополнительная сложность: Использование очереди как временной базы данных требует дополнительной инфраструктуры и управления, что может увеличить сложность системы.
🔻Ресурсозатратность: Постоянное поддержание очереди сообщений требует вычислительных ресурсов и места для хранения данных.

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

Приходилось кому-то использовать очереди в нестандартных кейсах? Расскажите в комментариях

Мы закончили цикл про брокеры и очереди. Теперь поговорим о формировании URL и о том, какие подводные камни нам могут встретиться в этом процессе. Для погружения в тему рассмотрим базовый контекст.

❓ Из чего состоит URL эндпоинта ❓

URL эндпоинта REST API — это адрес ресурса, который используется для взаимодействия между клиентом и сервером через HTTP-запросы. Он включает несколько ключевых компонентов, каждый из которых играет свою роль в формировании правильного пути до нужного ресурса. Вот структура URL эндпоинта REST API:
https://доменное_имя/версия_API/ресурс?параметры

✏️Основные компоненты URL

1️⃣ Протокол (https)
- Указывает протокол передачи данных. Чаще всего используется HTTP или HTTPS. Протокол определяет правила обмена информацией между клиентом и сервером.

2️⃣ Доменное имя (доменное_имя)
- Это уникальный идентификатор домена сервера, где находится ресурс. Например, example.com.

3️⃣ Путь к ресурсу (/версия_API/ресурс)
🔴Версия API: Часто путь начинается с версии API (например, /v1, /api/v2), чтобы обеспечить совместимость между разными версиями интерфейсов.
🔴Ресурс: Определяет конкретный объект или коллекцию объектов, с которыми вы хотите взаимодействовать. Ресурс может быть любым сущностью, например, пользователи (users), товары (products) и т.п.

4️⃣ Параметры запроса (?параметры)
- Дополнительная информация, передаваемая в виде пар ключ-значение после символа ?. Параметры позволяют уточнять запросы, фильтровать данные или передавать дополнительные параметры для операций. Каждый параметр отделяется символом &. Например, ?page=1&limit=10.

Пример полного URL:
https://example.com/api/v1/users?page=1&limit=10