В прошлой статье мы поняли, что такое API, а также разобрали такие базовые операции, как CRUD. А еще раньше поговорили про HTTP и HTTPS. Все эти знания пригодятся нам сегодня, ведь мы поднимем еще одну важную тему —Rest и SOAP. Для начала мы разберем эти технологии по отдельности, а затем четко определим, в чем разница между ними, чтобы вы точно дали верный ответ, если вас спросят об этом на собеседовании (P.S. А вас, скорее всего, спросят).
И так, что такое REST?
REST (Representational State Transfer — «передача репрезентативного состояния» или «передача состояния представления») - это архитектурный стиль взаимодействия компонентов приложения в сети. Архитектурный стиль - это набор ограничений и принципов проектирования свойств системы, которые необходимы для лучшего масштабирования и интеграции с другими сервисами.
То есть, важно понять, что Rest - это это набор правил, как программисту организовать написание кода серверного приложения. Впервые он был описан Роем Филдингом в его докторской диссертации в 2000 году.
REST не привязан к конкретному формату, хотя JSON стал де-факто стандартом из-за своей компактности и удобства использования в JavaScript. REST также поддерживает XML, HTML, текстовые данные и даже бинарные форматы.
REST преимущественно использует HTTP/HTTPS и опирается на стандартные HTTP-методы (GET, POST, PUT, DELETE). Это делает его интуитивно понятным и естественным для веб-среды. Несмотря на то, что REST часто используют в связке с HTTP, так как автор концепции REST — один из создателей протокола HTTP, REST может работать и с другими протоколами.
В REST для описания API часто используется спецификация OpenAPI/Swagger, но это не является обязательным требованием архитектурного стиля.
REST Требования
1. Отделение клиента от сервера (Client-Server). Код запросов остаётся на стороне клиента, а код для доступа к данным — на стороне сервера. Такое разделение позволяет создавать клиент и сервер независимо друг от друга, что ускоряет и упрощает разработку.
2. Отсутствие записи состояния клиента (Stateless). На сервере не хранится никаких данных о прошлых взаимодействиях с клиентом — каждый запрос должен содержать всю информацию для его обработки. Это снижает нагрузку на сервер, что особенно полезно, если к нему подключено одновременно много клиентов. Не нужно хранить дополнительную информацию о прошлых обращениях каждого из них. Достаточно обработать каждый запрос в отдельности.
3. Кэшируемость (Casheable). Если клиент запрашивает с сервера одни и те же данные по несколько раз, используется кэширование - есть сохранение части данных у клиента или на промежуточных серверах. Чтобы понять, какие данные надо кэшировать, а какие нет, в каждом ответе сервера на запрос есть пометка о том, можно ли его кэшировать.
4. Единство интерфейса (Uniform Interface). Должен быть единый способ обращения к каждому ресурсу. Все данные должны запрашиваться через один URL-адрес стандартными протоколами, например, HTTP. Для реализации единообразного интерфейса в REST API используется принцип HATEOAS (Hypermedia as the Engine of Application State). Суть HATEOAS в том, что сервер возвращает вместе с ресурсом информацию о связанных ресурсах и доступных действиях над ними.
5. Многоуровневость системы (Layered System). RESTful сервера могут располагаться на разных уровнях, при этом каждый сервер взаимодействует только с ближайшими уровнями и не связан запросами с другими.
Сервер - не единая сущность, между ним и клиентом есть несколько промежуточных узлов, выполняющих вспомогательные функции, — прокси-серверы. Никто из участников цепочки не знает всего пути, который проходит запрос, — только своих «соседей» справа и слева. Ни клиент, ни один из прокси-серверов не знает, к кому он обращается — к основному сервису или к другому прокси.
6. Код по требованию» (Code on Demand) - не обязательно. Сервер в ответ на запрос может отправить исходный код, который выполняется уже на стороне клиента. Благодаря этому можно передавать целые сценарии. Например, динамические элементы пользовательского интерфейса, написанные на JavaScript. В REST API требование необязательно, потому что не всем сайтам и сервисам нужно умение работать с готовыми скриптами.
Что такое SOAP?
SOAP (Simple Object Access Protocol - «простой протокол доступа к объектам»). — это протокол, по которому веб-сервисы взаимодействуют друг с другом или с клиентами. SOAP был разработан в 1998 году для компании Microsoft. Для обмена данным SOAP использует исключительно формат XML и любой из протоколов - HTTP, SMTP, TCP и даже JMS. Чаще всего — HTTP как наиболее универсальный: его поддерживают все браузеры и серверы.
Структура SOAP сообщения:
- Envelope — корневой элемент, определяющий XML-документ как SOAP-сообщение
- Header — необязательный элемент, содержащий метаданные и служебную информацию
- Body — обязательный элемент, содержащий основные данные сообщения
- Fault — необязательный элемент для описания ошибок
SOAP определяет жёсткие правила взаимодействия и передачи данных.
Стандарты SOAP
- Web Services Security — контролирует безопасность канала связи с помощью различных мер. Например, проверяет уникальные токены адресатов и отправителей.
- Web Services Addressing (WS-Addressing) — обязывает разработчиков внедрить механизм создания маршрутных сведений, которые привязываются к файлам в формате метаданных.
- WS-ReliableMessaging — выполняет обработку сбоёв и выводит сведения о них в сообщениях.
- Web Services Description Language — регулирует область эксплуатации и функциональность API.
Чтобы отправить запрос в API, нужно упаковать стандартный HTTP-запрос в конверт SOAP. Он преобразует исходный вариант в соответствии с обязательными правилами SOAP.
Важно отметить, что SOAP требует использования WSDL (Web Services Description Language) для формального описания предоставляемых веб-сервисом операций. Это добавляет дополнительный уровень сложности, но обеспечивает строгую типизацию и возможность автоматической генерации клиентского кода.
Rest и SOAP: отличия
Как вы уже и сами могли понять, Rest и SOAP - две разных технологии, которые, зачастую, используются в связке. Rest - это архитектурный стиль, а SOAP - это протокол.
- REST подходит для быстрого развертывания и масштабирования, SOAP — для сложных интеграций, требующих формализации и безопасности.
- REST легче воспринимается и проще реализуется, а SOAP требует более глубокого погружения в спецификации и стандарты.
- REST выигрывает в производительности и легкости внедрения, SOAP — в стабильности, безопасности и чёткости структуры.
Таким образом, REST — лучше использовать, когда:
- Разрабатываются веб- или мобильные приложения, где важна скорость загрузки, лёгкость интеграции и отзывчивость интерфейса.
- Планируется архитектура на основе микросервисов, когда каждый модуль живёт своей жизнью и должен быть легко разворачиваемым.
- Требуется взаимодействие с устройствами в среде интернета вещей (IoT) — REST идеально подходит благодаря поддержке лёгких HTTP-запросов.
- Необходима интеграция с публичными веб-сервисами и API, работающими на широком спектре технологий (JavaScript, Python, PHP и др.).
- Проект ориентирован на быстрое развитие, частые релизы, поддержку кросс-платформенных решений.
- Важно, чтобы API был понятен новым разработчикам, партнёрам или внешним интеграторам.
SOAP — лучше применять, если:
- Требуется интеграция в корпоративные системы, где уже используется SOAP-инфраструктура.
- Проект связан с финансовыми, медицинскими, страховыми сервисами, где критична безопасность и строгие политики доступа.
- Работа идёт с устаревшими платформами или сторонними системами, которые поддерживают только SOAP.
- Важна гарантированная доставка сообщений, а также обработка ошибок на уровне протокола.
- Проект проходит сертификацию по международным стандартам безопасности и надёжности.
Производительность и гибкость часто становятся решающими факторами при выборе между REST и SOAP. В контексте современных распределённых систем, где микросекунды и масштабируемость имеют значение, эти аспекты требуют особого внимания.
- Производительность REST-сервисов обычно превосходит SOAP по нескольким причинам:
- Меньший размер сообщений — JSON-сообщения в REST компактнее XML в SOAP на 30-50%.
- Меньшие накладные расходы — отсутствие дополнительных оберток для каждого сообщения.
- Эффективное кэширование — встроенные механизмы HTTP-кэширования.
- Более низкая сложность парсинга — обработка JSON обычно требует меньше ресурсов, чем XML.
SOAP, однако, предлагает дополнительные функции, которые иногда оправдывают его более низкую производительность:
- Встроенная поддержка WS-* стандартов (WS-Security, WS-ReliableMessaging, WS-Addressing).
- Транзакционность — возможность поддержки распределенных транзакций.
- Строгая типизация — предотвращение ошибок на этапе компиляции.
Заключение
Несмотря на то, что в современной веб-разработке лидирующую позицию занимает REST, ведь он легче осваивается, быстрее обрабатывает запросы, лучше подходит для мобильной разработки и требует меньше ресурсов, SOAP по-прежнему используется в корпоративных решениях с высокой степенью безопасности, поддержкой транзакций и стандартов, например в банковской или медицинской отраслях. Нередко эти технологии используются вместе, ведь тогда можно добиться оптимального баланса между скоростью и надёжностью.