SOAP или REST для веб-сервисов? [закрыто]

Я создал один из первых серверов SOAP, включая генерацию кода и поколение WSDL, от исходной спецификации, поскольку это разрабатывалось, когда я работал в Hewlett-Packard. Я НЕ рекомендую использовать SOAP для чего-либо.

акроним "SOAP" является ложью. Это не Просто, это не Объектно-ориентировано, это не определяет правил Доступа. Это - возможно, Протокол. Это - худшая спецификация Don Box когда-либо, и это - настоящий подвиг, как он - человек, который совершил "COM".

нет ничего полезного в SOAP, который не может быть сделан с REST для транспорта, и JSON, XML или даже простым текстом для представления данных. Для транспортной безопасности можно использовать https. Для аутентификации, основного автора Для сессий, существуют cookie. ОСТАЛЬНЫЕ присваивают версию, будет более простым, более ясным, работать быстрее и использовать меньше пропускной способности.

XML-RPC ясно определяет запрос, ответ и ошибочные протоколы, и существуют хорошие библиотеки для большинства языков. Однако XML более тяжел, чем Вам нужно для многих задач.

Если бы Вы ищете совместимость между различными системами и языками, я определенно пошел бы для REST. У меня было много проблем, пытающихся получить SOAP, работающий между.NET и Java, например.

Слушайте этот подкаст для обнаружения. Если Вы хотите знать ответ без слушания, то хорошо, его REST. Но я действительно рекомендую слушать.

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

мне любопытно относительно того, какие другие думают.

Это детально.

, Если у Вас должен быть другой системный интерфейс с Вашими сервисами, чем много клиентов, будет более довольно SOAP, из-за слоев "проверки", которую Вы имеете с контрактами, WSDL и стандартом SOAP.

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

Я уверен, что Don Box создал SOAP, поскольку шутка - 'смотрит, Вы можете методы RPC вызова по сети' и сегодня стонете, когда он понимает то, что чрезмерно увеличенный в размерах кошмар веб-стандартов это стало:-)

, REST хорош, прост, реализован везде (так больше 'стандарт', чем стандарты) быстрый и легкий. Используйте REST.

SOAP полезен с точки зрения инструментов, потому что WSDL так легко используется инструментами. Так, можно было генерировать клиенты веб-сервиса для Вас на Вашем любимом языке.

REST играет хорошо с веб-страницами AJAX'y. Если Вы сохраняете свои запросы простыми, можно сделать служебные вызовы непосредственно из JavaScript, и это входит очень удобное. Попытайтесь избегать наличия любых пространств имен в Вашем ответе XML, я видел дроссель браузеров на тех. Так, xsi:type, вероятно, не собирается работать на Вас, никакие чрезмерно сложные XML-схемы.

REST имеет тенденцию иметь лучшую производительность также. Требования ЦП кода, генерирующего ответы REST, имеют тенденцию быть ниже, чем, что показывают платформы SOAP. И, если у Вас есть свои утки поколения XML, выстроенные в линию на стороне сервера, можно эффективно передать XML потоком клиенту. Так, предположите чтение строк курсора базы данных. Поскольку Вы читаете строку, Вы форматируете ее как элемент XML, и Вы пишете что непосредственно в сервисного потребителя. Таким образом, Вы не должны собирать все строки базы данных в памяти прежде, чем начать писать Ваш вывод XML - Вы читаете и пишете одновременно. Изучите новые механизмы шаблонной обработки или XSLT, чтобы заставить потоковую передачу работать на REST.

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

Мой процесс принятия решений следующие: если я хочу, чтобы мой сервис был легко оснащен потребителями, и сообщения, которые я пишу, будут medium-to-small-ish (10 МБ или меньше), и я не возражаю записывать некоторые дополнительные циклы ЦП на сервере, я иду с SOAP. Если я должен служить Ajax на веб-браузерах, или мне нужна вещь передать потоком, или мои ответы являются гигантскими, я иду REST.

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

Не пропускайте XML-RPC. Если Вы сразу после легкого решения тогда существует много, чтобы быть сказанным для протокола, который может быть определен на нескольких страницах текста и реализован в минимальном объеме кода. XML-RPC был вокруг в течение многих лет, но пошел вышедший из моды некоторое время - но минималистское обращение, кажется, дает ему что-то вроде возрождения в последнее время.

Я рекомендовал бы пойти с REST сначала - если Вы используете взгляд Java на JAX-RS и Джерси реализация. REST намного более прост и легок к interop на многих языках.

, Поскольку другие сказали в этом потоке, проблемой с SOAP является своя сложность, когда другой WS -* спецификации входят и существуют бесчисленные проблемы interop, если Вы отклоняетесь в неправильные части WSDL, XSDs, SOAP, Обращение WS и т.д.

лучший способ судить остальных, v дебаты SOAP являются взглядом на Интернет - в значительной степени, все крупные игроки в интернет-пространстве, Google, амазонке, eBay, Твиттер и др. - склонны использовать и предпочитать УСПОКОИТЕЛЬНЫЕ API по SOAP.

другой хороший подход к движению с REST состоит в том, что можно снова использовать много кода и infratructure между веб-приложением и фронтэндом REST. например, рендеринг HTML по сравнению с XML по сравнению с JSON Ваших ресурсов обычно довольно легок с платформами как JAX-RS и неявные представления - плюс его легкое работать с УСПОКОИТЕЛЬНЫМИ ресурсами с помощью веб-браузера

SOAP в настоящее время имеет преимущество лучших инструментов, где они генерируют много шаблонного кода для обоих уровень служб, а также генерирующиеся клиенты от любого данного WSDL.

REST более прост, может быть легче поддержать, в результате лежит в основе веб-архитектуры, допускает лучшую видимость протокола и, как доказывали, масштабировался в размере самого WWW. Некоторые платформы там помогают Вам создать сервисы REST, как Ruby on Rails, и некоторые даже помогают Вам с пишущими клиентами, как Услуги передачи данных ADO.NET. Но по большей части, поддержке инструмента недостает.

REST является архитектурой, SOAP является протоколом.

Это - первая проблема.

можно отправить конверты SOAP в приложении REST.

сам SOAP является на самом деле довольно основным и простым, это - WSS -* стандарты сверху его, которые делают его очень сложным.

, Если Ваши потребители являются другими приложениями и другими серверами, существует большая поддержка протокола SOAP сегодня, и основы движущихся данных являются по существу щелчком мышью в современных IDE.

, Если Вашими потребителями, более вероятно, будут УСТЬЯ РЕКИ или клиенты Ajax, Вы, вероятно, захотите что-то более простое, чем SOAP, и более собственный клиенту (особенно JSON).

пакеты JSON, отправленные по HTTP, являются не обязательно архитектурой REST, это - просто сообщения к URL. Все совершенно осуществимые, но существуют ключевые компоненты остальным идиома. Легко перепутать два как бы то ни было. Но просто потому что Вы говорите, Запросы HTTP не обязательно означают, что у Вас есть архитектура REST. У Вас может быть приложение REST без HTTP вообще (ум, это редко).

Так, если у Вас есть серверы и потребители, которые "довольны" SOAP, стек SOAP и WSS может служить Вам хорошо. Если Вы делаете более специальные вещи и хотите лучше взаимодействовать через интерфейс с веб-браузерами, то некоторый более легкий протокол по HTTP может работать хорошо также.

REST является существенно различной парадигмой от SOAP. Хорошее чтение на REST может быть найдено здесь: , Как я объяснил REST своей жене .

, Если у Вас нет времени для чтения его, вот короткая версия: REST является определенным сдвигом парадигмы путем фокусировки на "существительных" и ограничения количества "глаголов", можно обратиться к тем существительным. Единственные позволенные глаголы, "получают", "помещают", "отправляют" и "удаляют". Это отличается от SOAP, где много различных глаголов могут быть применены ко многим различным существительным (т.е. многим различным функциям).

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

На практике, хотя большая часть из этого отпадает, и REST обычно просто обращается к простым Запросам HTTP, которые возвращают результаты в JSON, в то время как SOAP является более сложным API, который связывается путем передачи XML вокруг. У обоих есть их преимущества и недостатки, но я нашел, что, по моему опыту, REST обычно является лучшим выбором, потому что Вам крайне редко нужна полная функциональность, которую Вы получаете от SOAP.