Это, вероятно, действительно относится к комментариям в нескольких из вышеперечисленных постов, но у меня пока нет представителя, чтобы сделать это, поэтому здесь.
Мне кажется интересным, что многие плюсы и минусы, часто упоминаемые для SOAP и REST, имеют (IMO) очень мало общего с фактическими значениями или ограничениями двух технологий. Вероятно, наиболее цитируемым про для REST является то, что он «легкий» или имеет тенденцию быть более «читаемым человеком». На одном уровне это, безусловно, верно, REST имеет более низкий барьер для входа - там меньше требуемой структуры, чем в SOAP (хотя я согласен с теми, кто сказал, что хороший инструмент - это в основном ответ здесь - слишком плохая большая часть инструментов SOAP довольно ужасно).
Однако, помимо этой первоначальной стоимости входа, впечатление REST складывается из комбинации формы URL-адресов запроса и сложности данных, которыми обменивается большинство служб REST. REST имеет тенденцию поощрять более простые, более удобочитаемые URL-адреса запросов, и данные также становятся более удобочитаемыми. Однако в какой степени они присущи REST и в какой степени они просто случайны. Более простая структура URL является прямым результатом архитектуры - но она может быть одинаково хорошо применена к сервисам на основе SOAP. Более легко усваиваемые данные, скорее всего, будут результатом отсутствия какой-либо определенной структуры. Это означает, что вам лучше сохранять свои форматы данных простыми или вы будете заняты большой работой. Таким образом, здесь дополнительная структура SOAP, которая должна быть преимуществом, на самом деле обеспечивает небрежный дизайн, и этот неаккуратный дизайн затем используется как рывок против технологии.
Поэтому для использования в обмене структурированными данными между компьютерными системами я не уверен, что REST по своей природе лучше SOAP (или наоборот), они просто разные. Я думаю, что сравнение REST vs SOAP с динамической и статической типизацией является хорошим. Дианмические языки, как правило, сталкиваются с проблемами - это долгосрочное обслуживание и обслуживание системы (и в долгосрочной перспективе я не говорю год или два, я говорю 5 или 10). Будет интересно посмотреть, сталкивается ли REST с теми же проблемами со временем. Я склонен думать, что так будет, если бы я строил распределенную систему обработки информации, я бы склонялся к SOAP как к механизму связи (также из-за многоуровневой передачи и прикладного протокола и гибкости, которую он обеспечивает, как было упомянуто выше).
В других местах, хотя REST кажется более подходящим. AJAX между клиентом и его сервером (независимо от полезной нагрузки) является одним из основных примеров. У меня нет особой заботы о долговечности этого типа соединения, а простота использования и гибкость как минимум. Точно так же, если мне нужен был быстрый доступ к какой-либо внешней службе, и я не думал, что буду заботиться о возможности взаимодействия во времени (опять же, я предполагаю, что именно здесь REST обойдется мне дороже, в одну сторону или другой), тогда я мог бы выбрать REST только для того, чтобы я мог быстро входить и выходить.
В любом случае, они обе являются жизнеспособными технологиями, и в зависимости от того, какие компромиссы вы хотите сделать для данного приложения, они могут служить вам (или плохо).