Soap over http что это
Сравнение архитектурных стилей API: SOAP vs REST vs GraphQL vs RPC
Feb 4 · 12 min read
Два отдельных приложения нуждаются в посреднике, чтобы общаться друг с другом. Поэтому разработчики часто строят мосты — программные интерфейсы приложений, они же API, — чтобы предоставить одной системе доступ к информации или функциональности из другой.
Чтобы способствовать быстрой и масштабной интеграции приложений, API реализуются с использованием протоколов и/или спецификаций, определяющих семантику и синтаксис передаваемых сообщений. Эти спецификации составляют архитектуру API.
Со временем появились различные архитектурные стили API. Каждый из них содержит собственные схемы стандартизации обмена данными. Наличие выбора вызывает бесконечные споры о том, какой архитектурный стиль лучше.
Сегодня многи е пользователи API называют REST “Rest in peace” (“Покойся с миром”) и болеют за успех GraphQL, в то время как десять лет назад ситуация была обратной: REST как победитель, пришедший на замену SOAP. Проблема с этими мнениями в том, что они однобоко поднимают на щит какую-то технологию вместо того, чтобы рассматривать ее фактические свойства и характеристики относительно конкретной ситуации.
В этой статье мы останемся объективными и обсудим четыре основных стиля API в порядке их появления, сравним их сильные и слабые стороны и выделим сценарии, для которых каждый из них подходит лучше всего.
Удаленный вызов процедуры (RPC): вызов функции в другой системе
Удаленный вызов процедуры ( Remote Procedure Call) — это спецификация, которая позволяет удаленно выполнять функцию в другом контексте. RPC расширяет понятие локального вызова процедуры, но помещает его в контекст HTTP API.
Проблематичность первоначального XML-RPC связана со сложностями в обеспечении типов данных для полезных нагрузок XML. Позже API RPC задействовал более конкретную спецификацию JSON-RPC, которая считается более простой альтернативой SOAP. gRPC — последняя версия RPC, разработанная компанией Google в 2015 году. Благодаря подключаемым поддержке балансировки нагрузки, трассировки, проверки работоспособности и аутентификации gRPC хорошо подходит для микросервисов.
Как работает RPC
Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер. Получив сообщение, сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Стаб сервера и стаб клиента берут на себя сериализацию и десериализацию параметров.
Преимущества RPC
Простота и понятность взаимодействий. RPC использует GET для получения информации и POST для всего остального. Механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
Легкость добавления функций. Получив новое требование для API, мы можем легко добавить другую конечную точку, выполняющую это требование: 1) написать новую функцию и перебросить ее на конечную точку, и 2) теперь клиент может попасть в эту конечную точку и получить информацию, соответствующую заданному требованию.
Высокая производительность. Легкие полезные нагрузки легко распределяются по сети, обеспечивая высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сетях рабочих станций. RPC способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации, когда различные сервисы каждый день обмениваются тоннами сообщений.
Недостатки RPC
Плотная связь с базовой системой. Уровень абстракции API способствует его повторному использованию. Чем теснее связанность с базовой системой, тем хуже API подходит для других систем. Тесная связь RPC с базовой системой не позволяет создать уровень абстракции между функциями в системе и внешним API. Отсюда вытекают вопросы относительно безопасности, поскольку детали реализации базовой системы довольно легко просачиваются в API. Плотная связанность RPC создает трудности для требований к масштабируемости и слабо связанных команды. Таким образом, клиент либо беспокоится о возможных побочных эффектах вызова определенной конечной точки, либо пытается выяснить, какую конечную точку следует вызвать, потому что не понимает, по какому принципу сервер именует функции.
Низкая обнаруживаемость. В RPC нет никакого способа интроспектировать API или отправить запрос и начать понимать, какую функцию вызывать на основе его запросов.
Взрыв функций. Новые функции создавать очень легко. Поэтому вместо того, чтобы редактировать существующие, мы создаем новые, в результате чего получаем огромный список перекрывающихся функций, которые трудно понять.
Примеры использования RPC
Шаблон RPC получил первое применение примерно в 80-х годах, но это само по себе не делает его устаревшим. Крупные компании, такие как Google, Facebook (Apache Thrift) и Twitch (Twirp), используют внутри себя высокопроизводительные вариации RPC для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами. Их массивные системы микросервисов требуют, чтобы внутренняя коммуникация была четкой и в то же время организованной в короткие сообщения.
API для команд. RPC — подходящий выбор для отправки команд в удаленную систему. Например, Slack API очень командно-ориентирован: зайти на канал, покинуть канал, отправить сообщение. Разработчики Slack API как раз и смоделировали его в стиле RPC, сделав его маленьким, компактным и простым в использовании.
Клиентские API для внутренних микросервисов. В случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количества метаданных, как это делает REST API. gRPC и Twirp очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности. gRPC, с HTTP2 под капотом, способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой тонн сообщений в день. Однако, если вы стремитесь не к высокой производительности сети, а к стабильному API-контакту между командами, публикующими очень отличающиеся друг от друга микросервисы, REST позаботится об этом лучше.
Протокол доступа к простым объектам (SOAP): предоставление данных в виде сервисов
SOAP — это высоко-стандартизированный протокол веб-коммуникаций, основанный на формате XML. Выпущенный Microsoft через год после XML-RPC, SOAP многое от него унаследовал. Когда на сцену вышел REST, они сначала применялись параллельно, но вскоре REST выиграл конкурс популярности.
Как работает SOAP
Формат XML тянет за собой много формальностей. В сочетании с массивной структурой сообщений он делает SOAP самым подробным стилем API.
SOAP-сообщение состоит из:
Логика SOAP API написана на языке описания веб-служб (WSDL). Этот язык описания API определяет конечные точки и описывает все процессы, которые могут быть выполнены. Это позволяет различным языкам программирования и IDE быстро налаживать коммуникацию.
SOAP поддерживает обмен сообщениями с отслеживанием состояния и без такового. В сценарии с отслеживанием состояния сервер хранит полученную информацию, которая может весить очень много. Но это оправдано для многосторонних операций и сложных транзакций.
Плюсы SOAP
Независимость от языка и платформы. Встроенная функциональность для создания веб-сервисов позволяет SOAP обрабатывать сообщения и делать ответы независимыми от языка и платформы.
Связанность с различными транспортными протоколами. SOAP гибок с точки зрения протоколов передачи и приспосабливается к более чем одному сценарию.
Встроенная обработка ошибок. Спецификация SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
Ряд расширений безопасности. Благодаря интеграции с протоколами WS-Security качество транзакций SOAP соответствует корпоративным стандартам. SOAP гарантирует конфиденциальность и целостность внутри транзакций, обеспечивая при этом шифрование на уровне сообщений.
Минусы SOAP
В наши дни многие разработчики содрогаются при мысли о необходимости интеграции SOAP API по нескольким причинам.
Только XML. SOAP-сообщения содержат много метаданных и поддерживают только подробные XML-структуры для запросов и ответов.
Тяжеловесность. Из-за большого размера XML-файлов SOAP-сервисы требуют большой пропускной способности.
Узкоспециализированные знания. Создание серверов SOAP API требует глубокого понимания всех задействованных протоколов и их строгих правил.
Утомительное обновление сообщений. Требуются дополнительные усилия для добавления или удаления свойств сообщения — жесткая схема SOAP замедляет принятие.
Сценарии применения SOAP
В настоящее время архитектура SOAP чаще всего применяется для интеграции внутри предприятий или с их доверенными партнерами.
Надежность передачи данных. Жесткая структура SOAP, а также возможности в плане безопасности и авторизации, делают его наиболее подходящим вариантом для обеспечения соответствия формальному программному контракту между API и клиентом при соблюдении юридического контракта между поставщиком API и потребителем API. Вот почему финансовые организации и другие корпоративные пользователи выбирают SOAP.
Передача состояния представления (REST): предоставление данных в качестве ресурсов
REST — самоописательный архитектурный стиль API, определяемый набором архитектурных ограничений и предназначенный для широкого внедрения многими потребителями API.
Наиболее распространенный сегодня стиль API был впервые описан в 2000 году Роем Филдингом в его докторской диссертации. REST делает доступными данные на стороне сервера, представляя их в простых форматах — чаще всего это JSON и XML.
Как работает REST
REST определен не так строго, как SOAP. RESTful-архитектура должна соответствовать шести архитектурным ограничениям:
На самом деле, некоторые сервисы соответствуют стандарту RESTful только в определенной степени. Они берут за основу стиль RPC, разбивают более крупные службы на ресурсы и эффективно используют инфраструктуру HTTP. Но ключевое здесь — гипермедиа, иначе HATEOAS, сокращенно от “Гипертекст как двигатель состояния приложения” (Hypertext As The Engine of Application State). По сути это означает, что с каждым ответом REST API предоставляет метаданные, связывающие всю информацию о применении API. Это то, что позволяет отделить клиента от сервера. В результате и поставщик API, и потребитель API могут развиваться независимо и это не затрудняет их коммуникацию.
“HATEOAS — ключевая особенность REST. Это действительно то, что делает REST самим собой. Поскольку большинство людей не используют HATEOAS, они пользуются HTTP RPC”, — такое радикальное мнение встретилось мне на Reddit. Действительно, HATEOAS — это самая зрелая версия REST. Однако этой цели трудно достичь. Для этого требуются гораздо более продвинутые и интеллектуальные клиенты API, чем те, которые обычно создаются и действуют в наши дни. Таким образом, даже действительно хорошие REST API сегодня не всегда соответствуют стандарту. Вот почему HATEOAS в основном служит ориентиром для долгосрочного развития дизайна RESTful API.
Между REST и RPC действительно может находиться серая зона, когда сервис реализует некоторые функции REST и некоторые RPC. REST основан на ресурсе (или существительном), а не на действии (или глаголе).
В REST все делается с помощью HTTP-методов, таких как GET, POST, PUT, DELETE, OPTIONS и, надеюсь, PATCH.
Сравнение SOAP и REST с JSON [2019]
Jan 21, 2019 · 7 min read
Эта статья была в последний раз обновлена в январе 2019 года.
Веб-сервисы отвечают за интерактивное межмашинное взаимодействие. Компьютеры используют их для общения друг с другом через Интернет. Фактически, это только интерфейсные интерфейсы веб-сайтов и приложений, которые находятся на устройствах конечных пользователей.
Связанные данные хранятся на удаленном сервере и передаются на клиентский компьютер через API, которые предоставляют веб-сервисы сторонним пользователям. API могут использовать разные архитектуры для передачи данных с сервера на клиент.
Долгое время SOAP был протоко л ом обмена сообщениями, который использовался почти всеми веб-службами. Поскольку в наши дни разработчикам необходимо создавать легкие веб-приложения и мобильные приложения, более гибкая архитектура REST быстро завоевала популярность. В 2018 году большинство общедоступных веб-служб предоставили API-интерфейсы REST и передавали данные в компактном и простом в использовании формате обмена данными JSON. Однако корпоративные пользователи все еще часто выбирают SOAP для своих веб-сервисов. То же самое произойдет и в 2019 году.
Основные различия между SOAP и REST
SOAP и REST позволяют создавать собственный API. API означает интерфейс прикладного программирования. Это позволяет передавать данные из приложения в другие приложения. API получает запросы и отправляет ответы через интернет-протоколы, такие как HTTP, SMTP и другие. Многие популярные веб-сайты предоставляют общедоступные API-интерфейсы для своих пользователей, например, Google Maps имеет общедоступный REST API, который позволяет настраивать Google Maps с вашим собственным контентом. Есть также много API, которые были созданы компаниями для внутреннего использования.
SOAP и REST — это два стиля API, которые подходят к вопросу передачи данных с другой точки зрения. SOAP — это стандартизированный протокол, который отправляет сообщения с использованием других протоколов, таких как HTTP и SMTP. Спецификации SOAP являются официальными веб-стандартами, которые поддерживаются и разрабатываются Консорциумом World Wide Web (W3C). В отличие от SOAP, REST — это не протокол, а архитектурный стиль. Архитектура REST устанавливает набор рекомендаций, которым необходимо следовать, если вы хотите предоставить веб-службу RESTful, например, существование без сохранения состояния и использование кодов состояния HTTP.
Поскольку SOAP является официальным протоколом, он поставляется со строгими правилами и расширенными функциями безопасности, такими как встроенная совместимость с ACID и авторизация. Более высокая сложность требует большей пропускной способности и ресурсов, что может привести к снижению времени загрузки страницы. REST был создан для решения проблем SOAP. Поэтому у него более гибкая архитектура. Он состоит только из простых рекомендаций и позволяет разработчикам реализовывать рекомендации по-своему. Он допускает различные форматы сообщений, такие как HTML, JSON, XML и простой текст, в то время как SOAP допускает только XML. REST также является более легкой архитектурой, поэтому веб-сервисы RESTful имеют более высокую производительность. Из-за этого он стал невероятно популярным в эпоху мобильных устройств, где даже несколько секунд имеют большое значение (как по времени загрузки страницы, так и по доходам).
Что означает REST?
REST расшифровывается как представительский государственный трансферт. Это архитектурный стиль, который определяет набор рекомендаций для разработки слабосвязанных приложений, использующих протокол HTTP для передачи данных. REST не предписывает, как реализовать принципы на более низком уровне. Вместо этого, рекомендации REST позволяют разработчикам реализовывать детали в соответствии со своими потребностями. Веб-сервисы, созданные в соответствии с архитектурным стилем REST, называются веб-сервисами RESTful.
Чтобы создать REST API, необходимо соблюдать шесть архитектурных ограничений:
Какая основная причина использовать REST?
В 2018 году REST стал самым популярным выбором разработчиков для создания общедоступных API. Вы можете найти множество примеров по всему Интернету, тем более что все крупные сайты социальных сетей предоставляют API-интерфейсы REST, так что разработчики могут легко интегрировать свои приложения с платформой. Эти публичные API также поставляются с подробной документацией, где вы можете получить всю информацию, необходимую для извлечения данных через API.
REST и JSON
Архитектура REST позволяет поставщикам API доставлять данные в различных форматах, таких как простой текст, HTML, XML, YAML и JSON, что является одной из его самых любимых функций. Благодаря растущей популярности REST, легкий и читаемый человеком формат JSON также быстро завоевал популярность, так как он отлично подходит для быстрого и безболезненного обмена данными.
Чтобы увидеть разницу между XML и JSON, вот пример кода из документов API Crowd Serverкомпании Atlassian, который позволяет запрашивать и принимать данные в форматах XML и JSON:
Вот как выглядит приведенный выше XML-код в JSON:
Что означает SOAP?
SOAP означает простой протокол доступа к объектам. Это протокол обмена сообщениями для обмена данными в децентрализованной и распределенной среде. SOAP может работать с любым протоколом прикладного уровня, таким как HTTP, SMTP, TCP или UDP. Он возвращает данные получателю в формате XML. Безопасность, авторизация и обработка ошибок встроены в протокол и, в отличие от REST, не предполагают прямой связи точка-точка. Поэтому он хорошо работает в распределенной корпоративной среде.
SOAP следует формальному и стандартизированному подходу, который определяет, как кодировать XML-файлы, возвращаемые API. На самом деле сообщение SOAP — это обычный XML-файл, состоящий из следующих частей:
Вот как выглядит обычное SOAP-сообщение. Пример взят из документов W3C SOAP и содержит конверт SOAP, блок заголовка и тело:
Какая основная причина использовать SOAP?
В 2019 году SOAP, вероятно, продолжит использоваться для веб-сервисов уровня предприятия, которые требуют высокой степени безопасности и сложных транзакций. API-интерфейсы для финансовых услуг, платежных шлюзов, программного обеспечения CRM, управления идентификацией и телекоммуникационных услуг являются широко используемыми примерами SOAP. Одним из наиболее известных API-интерфейсов SOAP является общедоступный API- интерфейс PayPal, который позволяет принимать платежи через PayPal и кредитные карты, добавлять кнопку PayPal на ваш веб-сайт, разрешать пользователям входить в систему через PayPal и выполнять другие действия, связанные с PayPal.
Сравнительная таблица SOAP и REST
Хотя REST очень популярен в наши дни, SOAP по-прежнему занимает свое место в мире веб-сервисов. Чтобы помочь вам выбрать между ними, вот сравнительная таблица SOAP и REST, которая выделяет основные различия между двумя стилями API:
Что такое SOAP?
Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, если можно, пару примеров использования.
6 ответов 6
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding’и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
Минусов тоже полно:
В качестве примера есть открытый веб-сервис belavia:
Можете вручную создать и послать запрос типа:
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО, например: сайт на 1С-Битрикс, CRM 1С-Битрикс24, учетная система на базе 1С. Одни системы “из коробки” умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, В SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — Данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос “Какой способ реализации использовать?” необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в Битрикс
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, обращайтесь к нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков “заготовок” — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.