REST vs SOAP

#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...