Когда-то давным давно мне в журнале Хакер дали задание написать про SOAP. Я начал исследование и меня поразило, как же сложно все описывают эту тему. Большое количество заумных слов, особенно в статьях от IBM. Я попытался максимально упростить тогда свою статью про Web сервисы и SOAP, но сейчас я решил ещё раз вернуться к этой теме и ещё раз попробовать описать Web сервисы, так сказать много лет спустя.
Что такое SOAP? Это сокращение расшифровывается как Simple Object Access Protocol, что на великий и могучий язык можно повести как Простой Протокол Доступа к Объектам. И он действительно простой.
Если читать документацию IBM по сервисам, то там обязательно будут заумные вещи типа общей шины, какая-то ещё херня, но все это просто заумные слова, потому что на самом деле Web сервисы очень простые в использовании.
Запрос к Web сервису в самом простом случае поставляет из себя банальный HTTP запрос, с таким же заголовком и с такими же параметрами, как и у любого другого запроса к любым другим страницам сайта. У Microsoft сервисы могут работать по TCP для увеличения скорости, но это отдельная история, потому что сейчас мы затрагиваем SOAP – классику, с которой кажется и начинались все эти веб сервисы.
После заголовка HTTP вместо привычного HTML у SOAP идёт XML. Использовать HTML нельзя, потому что он не является таким строгим и тут можно творить практически что угодно. В XML все чуть более строго и вроде бы даже есть возможность определять данные (Data Definition), хотя эта возможность на мой взгляд дерьмовая, то-то её мало кто использует.
При запросах простых WEB страниц мы посылаем на сервер голый запрос или запрос с сериализрованными параметрами, а в ответ приходит HTML. В случае с SOAP и туда и сюда все передаётся в XML обёртке. Удобно, потому что все чётко отформатировано по заранее определённому формату и сервер с клиентом могут парсить XML и без проблем найдут данные, которые клиент хотел отправить серверу или сервер обратно клиенту.
Недостаток такого способа обмена информацией между клиентом и сервером – XML далеко не самый оптимальный формат с точки зрения парсинга, после получения запроса от клиента сервер тратит немало ресурсов на то, чтобы разобрать запрос и поместить данные в объекты в памяти компьютера. В IBM видно изначально это прочувствовали и поэтому с самого начала продумали, что можно ставить сразу несколько серверов приложений. Их масштабировать достаточно просто и в IBM явно на ресурсы плевать, ведь их конёк в то время были большие сервера.
На самом деле XML действительно очень удобен для передачи данных. Самое главное, что он в SOAP передаётся по HTTP, который уже идёт на 80-й порт, а этот порт открыт в большинстве систем сетевыми экранами. Не нужно открывать новых портов, за счёт открытости формата его легко читать и проверять на безопасность...
Для тестирования SOAP можно использовать даже любой простой TCP или HTTP клиент, который может передавать серверу произвольные данные, указанные пользователем.
Конечно же сервер и клиент е могут принимать совершенно любой XML, потому что они не могут знать, где в произвольном формате находятся нужные данные. Когда программисты создают новый сервис, то они определяют формат XML, в котором сервер будет принимать данные. Этот формат часто называют контрактом или WSDL. Наверно. Кажется так.
В общем, WSDL определяет, как должен выглядеть XML. Его знать не обязательно, потому что современные платформы автоматически создают такие контракты. Мы просто указываем, что сервис возвращает объекты определённого класса и специальные утилиты генерируют на основе этого класса WSDL. Потом на основе WSDL опять же специализированные утилиты могут сгенерировать что угодно, даже целые классы, которое будут готовы к тому, чтобы вызывать сервис. Например я пользуюсь программой SOAP UI, которая написана на Java, но умеет генерировать классы для C# и обладает визуальным интерфейсом, пусть и не самым удобным (простительно).
Да, я очень сильно упростил описание SOAP в этой заметке и все описал поверхностно, но в этом и был смысл, показать только основу, простоту и понять, зачем все это нужно. А дальше уже в книгах можно прочитать подробности. Когда я читал первую статью, то долго не мог понять, что же это за херня, и зачем оно мне нужно.
А в своей основе SOAP и веб сервисы всего лишь стандартизированный способ передачи данных между двумя точками. Если тебе нужно передать на сервер данные, чтобы он обработал их и вернул обратно, то можно:
1.Придумать свой собственный формат данных, который будет известен только вам и будет прекрасно работать
2.Использовать SOAP и его XML – который будет отформатирован по вашему желанию и сервер с клиентом будут искать в нем нужные данные.
Выбирате второе, не изобретайте велосипеда.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Михаил, подскажи пожалуйста ссылку на свою статью из Хакера про SOAP. Я не нашел ее.
А REST? Он реализован на базе SOAP или это что то новое?
REST идея почти та же - сервисная. Просто передается туда сюда не XML, а JSON или просто текст. Но это так же простые HTTP запросы к Web серверу. Хотя... SOAP все же может работать без WEB сервера, особенно на MS можно легко создать сервис, который будет запускаться как независимое приложение (не уверен, что это кто-то делает). REST все же без Web сервера я себе не представляю.
Разница еще в том, что SOAP обычно отправляется к одному URL и там уже по входным параметрам делят, что делать, в REST чаще для каждой операции создают свой собственный URL с разными методами доступа GET, POST, DELETE.
Но в своей идее и нижнем уровне они очень похожи. Разница в основном в основном в формате передаваемых данных
Статья, которая была в Хакере:
http://www.flenov.info/favorite.php?artid=36
Там конце есть ссылки на сайты IBM и др, где ужасно, просто ужасно описан SOAP. Столько заумных слов, а толку мало.
REST также может возвращать xml или еще что-нибудь. И никак не стандартизирован REST, это лишь набор нотаций, и все делают как хотят. Вроде как пережил 3 поколения, да появились POST GET PUT DEELETE что соответствует CRUD и др. И появился hateoas.
WEB Server для REST тоже не обязателен. У WebAPI есть возможность Self-Hosting и вообще он идеален для REST. На счёт форматов передачи данных считаю, что XML и даже JSON ужасно устарели, но если для работы с брузером у JSON нет альтернативы, то для мобильных, десктопных приложений и других сервисов можно использовать бинарные форматы такие как Protocol Buffers и Message Pack, сам работал с ними очень компактный ответ и очень большая скорость сериализации. JSON и тем более XML и рядом не стояли. Более того с WebAPI можно подключить хоть все 4 формата сразу, клиент передаёт заголовок Accept: MIME type и получает данные в том формате в котром хочет, я считаю это большой плюс в сравнии с SOAP который основан на исключительно на XML. Да и вообще корректней сравнивать не REST и SOAP, а REST и RPC, так как SOAP это и есть RPC только с ответами в формате XML и стандартизиваронной структурой.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
