Является ли SOAP теперь унаследованной технологией?

Question

Люди по-прежнему пишут SOAP services или это технология, которая прошла мимо ее architectural shelf life? Возвращаются ли люди в двоичные форматы?

Answer 1

Альтернатива SOAP не является двоичным форматом.

Я думаю, вы видите всплеск желания оставить сложность WS- * за поддержкой REST и JSON, потому что они гораздо проще в использовании и не требуют использования фреймворков. Проблемы, которые WS- * якобы пытается решить, не являются проблемами для большинства пользователей, но они должны платить за всю ее сложность.

Answer 2

Я все еще нахожу услуги на основе WS- * –. Несколько удивительно, что у меня было меньше проблем с ними при попытке взаимодействия с менее способными разработчиками. Это связано с тем, что, если я отправлю им файл WSDL, они знают, как прокручивать его через свой инструмент и получить API, который они могут назвать, в то время как блаженно не знают, что происходит под капотом. Чтобы предоставить клиентам услугу REST-ful, я должен начать говорить с ними о HTTP и XML, которые они действительно не понимают, как они думают, что они делают, а затем я начинаю получать головную боль.

Другими словами, чтобы быть успешным с REST, как поставщик услуг, так и потребитель должны знать, что они делают (и они могут упростить задачу и придумать отличное, не – WS- * решение). С технологиями WS- * он все равно может преуспеть, даже если только одна сторона имеет ключ.

Я думаю, однако, что стандарты, ориентированные на REST, которые намного менее сложны, чем существующие стандарты WS, в конечном итоге появятся, и когда это произойдет, будут доступны и сопоставимые инструменты.

Answer 3

Я бы не стал рассматривать SOAP-наследие вообще. REST vs. SOAP на самом деле является лишь продолжением обсуждения COM/CORBA и HTTP POST/GET и т. Д. SOAP - это не что иное, как обновленная версия тех же принципов, которые определены с C и C (контракты, поставщики, потребители и т. Д.), , Как оказалось, SOAP преуспел (по крайней мере частично), когда другие два не смогли (и это может быть то, что SOAP имеет только лучшую маркетинговую команду), то есть SOAP действительно позволяет различным системам подключаться довольно легко по сравнению с его предшественники. Тем не менее, он по-прежнему страдает от тех же недостатков, что и COM/CORBA ... он может стать очень сложным.

Я думаю, что REST просто вернется в стиль на данный момент. Это ничего нового, люди просто еще раз смотрят на это. Посмотрите в Интернете. Это REST, и это было уже много лет. Через 5 лет люди собираются оглянуться назад и сказать то же самое, что это наследие и необходимость изменения. Это характер разработки программного обеспечения. Все идет в цикле.

Дискуссия о том, какая из них лучше, будет такой же, как дискуссии с вкладками против пространств. Будут люди с разных сторон, которые ругаются, что лучше. В конце концов, они оба достигают той же цели. Конечно, в некоторых ситуациях это будет лучшим решением, чем другое, но в итоге ни один из них не будет превосходить 100% времени.

Answer 4

Думаю, что так. Решения RESTful более разумны для подавляющего большинства случаев использования; сложность SOAP и других технологий RPC просто не стоит усилий.

Answer 5

Мы использовали SOAP, но поскольку мы контролируем конечные точки обмена сообщениями (толстый клиент из Интернета, подключающийся к нашим серверам), мы решили, что «lingua franca» XML не предлагает никакой реальной выгоды. Вместо этого мы экспериментируем с бинарной сериализацией через буферы протокола Google и, как и все, что мы узнали до сих пор. Это немного CORBA-esque, но не делает меня сердитым, как CORBA. Все еще не нашли наилучшего соответствия для уровня RPC, но довольно уверен, что полезная нагрузка будет протокольным буфером.

Пункт, который я пытаюсь сделать, заключается в том, что если вы контролируете обе стороны разговора, есть значительные преимущества в области эффективности в обход налога XML.

Answer 6

Да, некоторые люди все еще (и теперь это 2011!). Я думаю, что основная причина заключается в том, что MS WCF автоматически генерирует привязки SOAP. Ужас.

Answer 7

Невозможно определить, что представляет собой лучшее технологическое решение, не учитывая, в чем проблема, другими словами, что такое контекст. И REST, и SOAP имеют свое место. Если у вас есть сайт с высоким трафиком и аудитория разработки, которая удобна в REST, SOAP будет плохим выбором, в первую очередь потому, что размер сообщения настолько невероятно раздутый. Если у вас небольшой сайт с небольшим бюджетом разработки, то SOAP будет лучшим выбором из-за автоматического создания прокси-сервера из WSDL. Чтобы сделать справедливое сравнение, следует упомянуть, что реализация диалога REST требует большего времени разработки и, следовательно, более дорогостоящего, очень важного факта для вашего босса.

Хотя верно, что SOAP - более сложный протокол, по моему опыту это не переводит на проблемы ремонтопригодности. Это связано с тем, что сообщения передаются по HTTP и могут быть легко отлажены точно так же, как сообщение REST, а стеки SOAP, доступные на основных платформах, очень прочные.

Сложность SOAP, конечно же, является преимуществом, если ваши требования включают сложные элементы, такие как безопасность объединенного сообщения. С другой стороны, такого рода требования не наблюдаются часто в моем опыте. Комитет по стандартам WS, возможно, был уязвим для некоторых вопросов YAGNI. Теперь, когда общение с веб-сервисами является обычным явлением, оно оказывается более простым, чем первоначально предполагалось.