В чем разница между веб-службами SOAP и REST? Может ли SOAP быть RESTful?

Из журнала MSDN https://msdn.microsoft.com/en-us/magazine/dd315413.aspx и https://msdn.microsoft.com/en-us/magazine/dd942839.aspx Я понимаю, что

Когда конечные точки RESTful запрашивают данные с использованием HTTP, используемым HTTP-глаголом является GET.

Использование REST означает, что вы можете использовать кеширование HTTP и другие функции, такие как Conditional GET, которые помогают в масштабировании сервисов. Многие из этих методов не могут использоваться с SOAP, поскольку SOAP использует POST только через HTTP.

На странице Википедии http://en.wikipedia.org/wiki/Representational_state_transfer

RESTful-системы обычно, но не всегда, обмениваются данными по протоколу передачи гипертекста с теми же HTTP-глаголами (GET, POST, PUT, DELETE и т.д.), которые используются веб-браузерами для извлечения веб-страниц и отправки данных на удаленные серверы.

Но будет ли нарушение архитектуры REST использовать HTTP POST для получения данных из ресурса? Другими словами, может ли веб-служба на основе SOAP быть RESTful?

Существуют ли какие-либо другие различия между веб-службой на основе RESTful и SOAP?

ОТВЕТЫ

Ответ 1

Введение

Я отправляю это как ответ, потому что комментариев просто не хватает. Вот что я хочу обобщить для вас.

Сначала мы начнем с этих двух ссылок:

http://spf13.com/post/soap-vs-rest

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/

Наконец, я хочу начать этот пост, сказав следующее:

SOAP и REST были разработаны для решения следующей проблемы: как два разных приложения, программы или устройства обмениваются и обмениваются данными друг с другом в расширяемом и легко понятным способом?

Услуги RESTful

По дизайну RESTful ( Re презентация S tate T ransfer) службы используют HTTP, а HTTP глаголы (GET, POST, PUT, DELETE), чтобы указать намерение. Эти глаголы очень четко указывают пользователю, что произойдет, когда они будут использоваться. Сервер может использовать их для принятия превентивных решений. То есть, он может принять решение задолго до того, как действие будет готово.

Учтите это, вам нужно получить доступ к небольшому количеству данных из учетной записи Вставить службу. Что проще, запрос GET endpoint/users/account/id или запрос POST endpoint/users/account, который имеет тело id? По определению REST запрос POST нарушает основное соглашение, которое подразумевает REST. То есть: ожидается, что сервер узнает, прежде чем данные прибудут, какие намерения у него есть у пользователя. Это основная основа, которую пытается гарантировать REST.

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

Другой аспект REST (особенно с Twitter, Facebook и Google): Службы RESTful, с фокусом и мандатом на HTTP, могут воспользоваться заголовками ответов HTTP. То есть, они могут отвечать сообщением HTTP 403 Forbidden, если клиенту не разрешен доступ. службы SOAP не могут. В результате сообщение должно указать такой результат.

службы RESTful имеют тенденцию связывать HTTP verbs (или действия) с существительными (или объектами/объектами). Вообще говоря, множественность и сингулярность подразумевают больше действий. То есть Ожидается, что GET RootEndpoint/Employees вернет сотрудников all (или, по крайней мере, большая группа, соответствующая конкретным критериям). В то время как GET RootEndpoint/Employee/12 ожидается возврат только одного сотрудника. (Как правило, Сотрудник с ID 12.)

службы RESTful обеспечивают прямую корреляцию между HTTP verb (GET, POST, PUT, DELETE) и действием. Это цель связи между ними: нет ничего особенного, которое необходимо добавить в тело сообщения, чтобы указать, что пользователь намеревается сделать. (Я буду продолжать подчеркивать этот момент.)

REST был полностью разработан для HTTP. И это очень хорошо работает.

Фильтрация RESTful

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

Я приведу пример из Spotify API: https://developer.spotify.com/web-api/get-playlist/:

Получить список воспроизведения

Получить плейлист, принадлежащий пользователю Spotify.

Конечная точка

GET https://api.spotify.com/v1/users/{user_id}/playlists/{playlist_id}

Параметры запроса

+---------------------------------------------------+
| Path parameter | Value                            |
+---------------------------------------------------+
| user_id        | The user Spotify user ID.      |
| playlist_id    | The Spotify ID for the playlist. |
+---------------------------------------------------+

В этой конечной точке API вы указываете, что вы ищете объект users с user_id объекта {user_id} и playlists (внутри этого объекта users) с помощью playlist_id of HTTP T232 > .

Некоторые службы RESTful позволяют сочетать флаги с параметрами.

Возьмите, например, API-интерфейс стека. Вы можете получить несколько вопросов или ответов, разделив их точкой с запятой и, по сути, отфильтруйте только те вопросы или ответы.

Если мы проанализируем эту конечную точку (/questions/{ids}/answers), вы увидите, что она указывает:

Получает ответы на набор вопросов, идентифицированных в id.

Этот метод наиболее полезен, если у вас есть набор интересных вопросов, и вы хотите получить все свои ответы сразу или если вы проводите опрос для новых или обновлений ответов (в сочетании с sort = activity).

{ids} может содержать до 100 идентификаторов с разделителями с запятой, чтобы найти идентификаторы программным образом для поиска question_id объектов вопроса.

Виды, принятые этим методом, работают в следующих полях объекта ответа:

Это также хороший пример API, который позволяет дополнительным запросам GET фильтровать/сортировать результаты еще дальше.

Пример использования: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow

Теперь, если мы сделаем то же самое с /answers/{ids} конечной точкой, мы можем придумать что-то вроде строк: https://api.stackexchange.com/2.2/answers/30582379;30581997;30581789;30581628?order=desc&sort=activity&site=stackoverflow. Это набирает четыре указанных ответа для нас.

Мы можем объединить еще больше, например, с SE API и включить фильтры для ограничения возвращаемых полей: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow&filter=!)V)P2Uyugvm. (См. эту ссылку в /2.2/filters для объяснения этого параметра filter.)

Службы на основе SOAP

Введите SOAP ( S imple O bject A ccess P rotocol), который был предшественником REST. SOAP решил эту проблему, отправив сообщения туда и обратно. Они используют XML (хотя вы можете создать SOAP-основанную службу без него, аналогично возможности создания RESTful службы без JSON) для обмена сообщениями, при этом у сервера нет начального указания на то, что делать.

Службы на основе SOAP решают эту проблему таким образом, который является агностиком транспортной среды. Сервер и клиент не должны использовать HTTP или даже TCP вообще. Им просто нужно использовать одни и те же или совместимые транспортные среды. Фактически, вы могли бы думать о современной корпоративной среде как о SOAP-основе. Когда вам нужно получать новые материалы, вы отправляете заявку своему офис-менеджеру, который затем отвечает сообщением. Получив первоначальную заявку, ваш менеджер понятия не имеет, разрешено или нет. Они должны прочитать остальную часть заявки, чтобы определить, является ли она действительным запросом или недействительна.

SOAP был спроектирован вокруг RPCs (вызовы с удаленной процедурой), многие брандмауэры блокируют их. Таким образом, SOAP был изменен для работы над HTTP. Он был разработан для интеграции самых разных технологий.

Поскольку SOAP предназначен для сообщений, это гораздо более подробный сервис. Обычно проще представлять составные действия в службах SOAP. То есть, если вы запрашиваете objects на основе критериев many (вместо одного) SOAP имеет лучший интерфейс для этого.

Фильтрация на основе SOAP

Фильтр служб на основе SOAP с дополнительными полями в RPC. Комбинация этих полей зависит от поставщика.

Я возьму пример из Глобального API погоды: http://www.webservicex.net/globalweather.asmx?op=GetWeather:

GetWeather

Получить прогноз погоды для всех крупных городов мира.

Test

Чтобы протестировать операцию с использованием протокола HTTP POST, нажмите кнопку "Вызов".

+---------------------------------------------------+
| Parameter      | Value                            |
+---------------------------------------------------+
| CityName:      |                                  |
| CountryName:   |                                  |
+---------------------------------------------------+

Если вы укажете, например, "Blanding" и "United States", вы увидите, что сгенерированный XML выглядит следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <GetWeather xmlns="http://www.webserviceX.NET">
      <CityName>Blanding</CityName>
      <CountryName>United States</CountryName>
    </GetWeather>
  </soap12:Body>
</soap12:Envelope>

Это будет отправлено (для HTTP-запроса SOAP) в качестве запроса на основе POST для http://www.webservicex.net/globalweather.asmx/GetWeather.

Вернуться к исходному вопросу:

Может ли веб-служба на основе SOAP быть RESTful?

Это был ваш первоначальный вопрос, и я считаю, что разумно, что он не может, основываясь на информации, которую я предоставил. Эти две службы являются взаимоисключающими. REST намерен решить проблему с обменом headers, указывающим на намерение, и message bodies, которые указывают цель. SOAP намерен решить проблему с обменом messages, который указывает намерение и цель.

Будет ли нарушение архитектуры REST использовать HTTP POST для получения данных из ресурса? Да. Архитектура службы RESTful предназначена для использования термина POST для представления конкретного действия. Каждый HTTP verb в REST представляет то, что намеревается сделать это действие.

Как я уже сказал в комментариях по первому вопросу:

Вы можете использовать HTTP POST для получения данных, но это не служба RESTful, а HTTP verb не имеет значения. RESTful - RESTful, потому что глагол указывает на действие.

Что мне выбрать, SOAP или REST?

Эта часть существует прежде всего для будущих читателей.

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

Ответ 2

REST использует HTTP-глаголы, чтобы сформулировать, какое действие вы пытаетесь выполнить.

Запрос "GET" просит службу вернуть элемент в определенном месте.

Запрос "POST" просит службу создать новый объект в местоположении (который, вероятно, будет сохраняться в БД за кулисами).

Запрос "PUT" просит сервис обновить существующий объект в местоположении.

Запрос "DELETE" просит службу удалить существующий объект в местоположении.

Нет, вы не можете использовать "POST" для чего-то вроде "GET" и по-прежнему называете себя REST API. Ваши потребители будут действительно смущены этим.

Ответ 3

Концептуально, услуги очень разные.

SOAP - это вызовы удаленных процедур (RPC), что означает, что он предназначен для удаленного вызова методов. Прокси серверных методов на клиенте должен оставаться в синхронизации с сервером. WSDL обычно используется для синхронизации моделей.

SOAP также игнорирует множество функций HTTP. Как вы уже упоминали, он использует методы POST для всего. Он также переносит данные в собственный формат данных XML.

REST использует URL-адреса для ссылок на ресурсы. Представление ресурса может быть в любом формате (json, xml, csv, binary,...) и может использовать согласование HTTP-содержимого (Accept * headers). Методы HTTP очень хорошо отображают методы CRUD.

Истинные службы REST должны использовать формат данных, который управляется гипермедиами (HAL, коллекция JSON,... или пользовательский заказчик). Он предоставляет возможность обнаруживать ссылки на связанные ресурсы с одного фиксированного URL.

http://en.wikipedia.org/wiki/HATEOAS

Я не вижу, как одна и та же услуга (один контракт) может соответствовать всем этим критериям.

Ответ 4

Да есть различия.

Конечные точки службы будут отличаться друг от друга.

Вы можете использовать все HTTP-глаголы без проблем для своей службы RESTful.

В RESTful вы можете отправить json вместо XML. Посмотрите на пример прямо здесь.

<services>
  <service name="TestService">
    <endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
    <endpoint address="json" binding="webHttpBinding"  behaviorConfiguration="jsonBehavior" contract="ITestService"/>
  </service>
</services>