Комментарии 6
Да никто в здравом уме сейчас новые сервисы на соапе поднимать не будет,
куча старых тяжелых систем, да на нем работают,
но делать новые используя самый тяжеловесный протокол? Да ну нафиг.
Там где крутятся данные о больших деньгах, и соответственно и речь о больших рисках в случае утечки данных, то будут. Про мелкие компании никто и не говорит, ибо они в большинстве своём и нафик никому не уперлись, чтобы тратить силы на взлом их протоколов. Там rest самое то. А для крупных игроков,не вложится в разработку на основе тяжёлых протоколов - себе дороже. О чем собственно и статья
А расскажите мне насколько лучше защита при передаче SOAP-ом от любого другого протокола, если передаем по https например?
И передаем документы подписаные КЭП? Да и зашифровать можем хоть сто раз более надежными методами.
Надежность доставки тоже реализуется любыми другими способами.
Да и то что описано возможно никогда ни одной библиотекой в полной мере не было реализовано в принципе. По крайней мере все то что я встречал тупо открытую xml передавало, а токен отдельным парамтров http запроса не имеющего отношения soap.
А вот как раз для финансовой отрасли сейчас важна скорость при диких объемах и тут соап далеко сзади тащится.
В данный момент интегрируюсь со "свежим" сервсом на SOAPe.
Смешались в кучу
Кони, люди...
https://ru.wikipedia.org/wiki/REST
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом.
Есть такая нидерландская компания TenneT - крупный энергетический оператор. В 2001 году они решили обновить свой софт и сервисы для сторонних клиентов. Раньше по-старинке обменивались файликами по FTP, а надо что-то новое уже применить, XXI век всё-таки!
Собрали комитет, рассмотрели варианты и выбрали самую новую технологию - SOAP! WS-Addressing, WSSE, токены-шмокены, подписи и сертификаты..
Ну и начали внедрять. Написали спецификации, нашли программистов и начали! Надо было всё делать параллельно с уже существующей системой, так что не торопились.
Внезапно, настал 2021 год. Наконец, объявили, что первая фаза закончена и можно клиентам начинать мигрировать в тестовом порядке. Это тот момент, когда мне дали задачу подключиться и попробовать что-то отправить в это API.
Скажу я вам, это пример того, как за 20 лет бывшая новая технология оказывается на свалке! Я пишу на Python и, в принципе, там есть более-менее рабочие библиотеки для SOAP, но то что нужно для TenneT - видимо, не используется уже больше нигде, поскольку поддержки половины фич просто не было. С миру по нитке, я за три месяца кое-как научился подписывать и отправлять правильно выглядящий XML. Только он не принимался. Неправильная подпись - и всё тут. Знакомые джависты на вопросы отвечали что такой археологией не занимаются. Я пробовал C#, Java, но там даже собрать приложение было проблемой - все примеры в интернете ссылались на слишком старые версии библиотек.
Перечитав весь интернет три раза, я, наконец, наткнулся на описание бага, подозрительно похожего на мою проблему. Связался с его автором и он мне рассказал что через php он смог отправить пакет и он был корректно принят..
В итоге у меня приложение на Python вызывает php-скрипт, который через SOAP отправляет запрос, принимает ответ и возвращает всё обратно в Python. Все поля xml-конверта выглядят идентично моим в python, но, видимо, подпись как-то отличается. Ненавижу этого монстра всем сердцем, но приходится так работать.
В 2024 году TenneT объявила, что всё, уже-таки дедлайн и всем уже обязательно надо переключаться на новую версию. Народ забегал и теперь уже у меня начали какие-то левые люди спрашивать совета..
Расширенные возможности SOAP и когда он нужен?