SOAP和REST Web服务之间有什么区别?SOAP可以是RESTful的吗? [英] What is the difference between SOAP and REST webservices? Can SOAP be RESTful?

问题描述

来自MSDN杂志 https://msdn.microsoft.com/en-us/magazine/dd315413.aspx 和 https://msdn.microsoft.com/en-us/magazine/dd942839.aspx 我明白

使用HTTP请求RESTful端点提供数据时，使用的HTTP动词为GET.

使用REST意味着您可以利用HTTP缓存和其他功能(如条件GET)来帮助扩展服务.其中许多技术无法与SOAP一起使用，因为SOAP仅通过HTTP使用POST.

从Wikipedia页面 http://en.wikipedia.org/wiki/Representational_state_transfer

RESTful系统通常(但并非总是)通过超文本传输​​协议与网络浏览器用来检索网页并将数据发送到远程服务器的相同HTTP动词(GET，POST，PUT，DELETE等)进行通信.[

但是使用HTTP POST从资源中获取数据是否违反REST体系结构??换句话说，基于SOAP的Web服务是否可以是RESTful的?

RESTful和基于SOAP的Web服务之间还有其他区别吗?

解决方案

简介

我将其发布为答案，因为评论还不够.这是我想为您总结的.

首先，我们将从以下两个参考开始:

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

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

最后，我想通过说以下内容开始这篇文章:

SOAP 和 REST 都旨在解决以下问题:两个互不相同的应用程序，程序或设备如何在彼此之间交换和共享数据彼此之间，以一种可扩展且易于理解的方式?

---

RESTful服务

通过设计 RESTful (重新代表性的 S tate T Transfer)服务使用 HTTP 和 HTTP 动词( GET ， POST ， PUT ， DELETE )来表示意图.这些动词非常清楚告诉用户使用它们时会发生什么.服务器可以使用它们来做出抢占决策.也就是说，它可以早于动作准备就绪就可以做出决定.

考虑到这一点，您必须从用户插入服务帐户访问少量数据.使用 GET端点/用户/帐户/id 请求或使用 id POST端点/用户/帐户请求更容易>?根据 REST 的定义， POST 请求违反了 REST 所暗示的基本协议.也就是说:服务器有望在数据到达之前就知道用户的意图.这是 REST 试图保证的基本基础./p>

这个事实(没有这个基本原则)要求允许 RESTful 通信来指示客户端在开始发送数据之前客户端的意图.这样一来，服务器就可以在消息到达之前很长时间接受和拒绝，从而减轻了处理负担.

REST的另一个方面(尤其是 Twitter ， Facebook 和 Google API):以 HTTP 为重点和任务的RESTful 服务可以利用 HTTP 响应标头.也就是说，如果不允许客户端访问，则他们可能会使用 HTTP 403 Forbidden 消息进行响应.基于SOAP 的服务可能不会.结果消息必须表明这样的结果.

RESTful 服务倾向于将 HTTP动词(或动作)与名词(或实体/对象)相关联.通常，复数和单数表示更多关于动作的信息.IE.预计 GET RootEndpoint/Employees 将返回所有员工(或至少一个符合特定条件的大集团.)而 GET RootEndpoint/Employee/12 应该只能返回一名员工.(通常是ID为12的员工.)

RESTful 服务在 HTTP动词( GET ， POST ， PUT ， DELETE )和 action.这是两者之间联系的目的:不需要添加任何特殊内容消息正文以指示用户打算做什么.(我将继续强调这一点.)

REST 完全是为 HTTP 设计的.而且，非常擅长于此.

RESTful过滤

通常来说，要过滤 REST 服务请求，您将包括多个URL段，每个段都指示紧随其后的参数.

我将以Spotify API为例: https://developer.spotify.com/web-api/get-playlist/:

获取播放列表

获取Spotify用户拥有的播放列表.

端点

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

请求参数

  + --------------------------------------------------- +|路径参数|价值|+ --------------------------------------------------+|user_id |用户的Spotify用户ID.||playlist_id |播放列表的Spotify ID.|+ --------------------------------------------------+ 

在该API端点中，您指定要查找具有 {user_id} 的 user_id 的 users 对象和>播放列表对象(在该 users 对象中)，其 playlist_id 为 {playlist_id} .

某些RESTful服务允许在参数上使用组合标志.

以Stack Exchange API为例.您可以使用分号将多个问题或答案分开，这样基本上可以过滤出这些问题或答案.

如果我们分析此端点(/questions/{ids}/answers)，您将看到它指定了:

获取ID中标识的一组问题的答案.

如果您有一组有趣的问题，并且希望一次获得所有答案，或者要轮询新答案或更新答案(与sort = activity结合使用)，则此方法最有用.

{ids} 最多可以包含100个以分号分隔的ID，以编程方式查找ID可以在问题对象上查找 question_id .

此方法接受的排序对答案对象的以下字段进行操作:

这也是API的一个很好的示例，该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 简单的 O 将 A 访问 P rotocol)，它是 REST 的前身. SOAP 通过来回发送消息来解决此问题.他们使用 XML (尽管您可以在没有它的情况下构建基于 SOAP的服务，这与无需就可以构建 RESTful 服务类似)JSON )来交换消息，从而使服务器没有任何初始指示.

基于SOAP 的服务以与传输介质无关的方式解决了此问题.服务器和客户端根本不需要使用 HTTP 甚至是 TCP .他们只需要使用相同或兼容的传输介质即可.实际上，您可以将现代公司环境视为一种基于SOAP 的服务.当您需要购买新耗材时，您向办公室经理提出了一个请购单，然后他会以一条消息进行回应.收到初始申请后，您的经理不知道(是否允许).他们必须阅读其余申请，才能确定这是一个有效的请求还是无效的请求.

SOAP 是围绕 RPCs (远程过程调用)设计的，许多防火墙阻止了它们.因此，结果， SOAP 被修改为可以在 HTTP 上使用.它旨在集成完全不同的技术.

因为 SOAP 是围绕消息设计的，所以它是很多的详细服务.通常，在 SOAP 服务中表示复合动作比较容易.也就是说，如果您基于许多标准(而不是一个标准)请求 objects ， SOAP 往往具有更好的接口.

基于SOAP的过滤

基于SOAP的服务使用RPC中的其他字段进行过滤.这些字段的组合方式取决于提供商.

我将以Global Weather API为例: http://www.webservicex.net/globalweather.asmx?op=GetWeather :

GetWeather

获取全球所有主要城市的天气报告.

测试

要使用HTTP POST协议测试操作，请点击调用"按钮.

  + --------------------------------------------------- +|参数价值|+ --------------------------------------------------+|城市名称:|||CountryName:||+ --------------------------------------------------+ 

例如，如果您指定"Blanding"，和美国"您将看到生成的XML如下所示:

 <?xml version ="1.0"encoding ="utf-8"?< soap12:信封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>美国</CountryName></GetWeather></soap12:Body></soap12:Envelope> 

这将作为对POST的基于POST的调用(对于HTTP SOAP请求)提交给 http://www.webservicex.net/globalweather.asmx/GetWeather .

---

回到原始问题:

基于SOAP的Web服务可以是RESTful吗?

这是您最初的问题，根据我提供的信息，我相信这是有理由不能这样做的原因.这两个服务是互斥的. REST 旨在通过交换表示意图的 headers 和 message body来解决该问题.表示目的. SOAP 旨在通过交换表示意图和目的的 messages 来解决该问题.

使用HTTP POST从资源中获取数据是否违反REST体系结构?是. RESTful 服务体系结构设计为使用术语 POST 表示特定的操作. REST 表示该操作打算做什么.

正如我在对第一个问题的评论中所说的:

您可以使用 HTTP POST 来获取数据，但是它不是 RESTful 服务，因为 HTTP动词没有任何意义. RESTful 服务是 RESTful 服务，因为动词表示动作.

---

我该选择什么，SOAP还是REST?

这部分主要供将来的读者使用.

这两种协议都有优点和缺点，您应该根据问题的要求选择要使用的协议.指导您如何完成此任务超出了本问答的范围.也就是说，要考虑以下三件事:了解您的项目，了解您的需求，并且最重要的是，正确地为您的受众记录它.

From MSDN magazine https://msdn.microsoft.com/en-us/magazine/dd315413.aspx and https://msdn.microsoft.com/en-us/magazine/dd942839.aspx I understand that

When RESTful endpoints are asked for data using HTTP, the HTTP verb used is GET.

Using REST means that you can take advantage of HTTP caching and other features, like Conditional GET, that aid in scaling services. Many of these techniques can't be used with SOAP because SOAP uses POST only over HTTP.

From the Wikipedia page http://en.wikipedia.org/wiki/Representational_state_transfer

RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.[

But will it be a violation of REST architecture to use HTTP POST to get data from a resource? In other words, can a SOAP based webservice be RESTful?

Are there any other differences between RESTful and SOAP based webservice?

解决方案

Introduction

I'm posting this as an answer because comments just don't suffice. Here is what I want to summarize for you.

First, we'll start with these two references:

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

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

Lastly, I want to start this post off by saying the following:

SOAP and REST were both designed to solve the following problem: how do two disparate applications, programmes or devices interchange and share data between each other, in an extensible and easily-understood manner?

---

RESTful Services

By design RESTful (Representational State Transfer) services use HTTP and the HTTP verbs (GET, POST, PUT, DELETE) to indicate intent. These verbs very clearly indicate to the user what is going to happen when they are used. The server can use them to make preemptive decisions. That is, it can make a decision long before the action is ready to take place.

Consider this, you have to access a small bit of data from a users Insert Service account. Which is easier, a GET endpoint/users/account/id request, or a POST endpoint/users/account request that has a body of id? By definition of REST, the POST request violates the basic agreement that REST implies. That is: the server is expected to know, before the data has arrived, what intentions with it the user has. This is the basic fundamental that REST attempts to guarantee.

This fact, no, this fundamental, mandates that RESTful communication be permitted to indicate what intention the client has before the client begins to send data. This allows the server to accept and reject messages long before they arrive, thus reducing processing load.

Another aspect of REST (especially with the Twitter, Facebook and Google APIs): RESTful services, with the focus and mandate on HTTP, can take advantage of HTTP response headers. That is, they may respond with an HTTP 403 Forbidden message if the client is not permitted access. SOAP-based services may not. The resulting message must indicate such a result.

RESTful services tend to associate HTTP verbs (or actions) with nouns (or entities/objects.) Generally speaking, plurality and singularity imply more about the action. I.e. GET RootEndpoint/Employees would be expected to return all employees (or at least a large group matching a specific criteria.) Whereas GET RootEndpoint/Employee/12 would be expected to return only one employee. (Generally, Employee with ID 12.)

RESTful services make a direct correlation between the HTTP verb (GET, POST, PUT, DELETE) and the action. This is the purpose of the tie between the two: there is nothing special that needs added to the message body to indicate what the user intends to do. (I'll continue to stress this point throughout.)

REST was designed entirely for HTTP. And it is very good at it's job.

RESTful Filtering

Generally speaking, to filter REST service requests you would include multiple URL segments with each segment indicating what parameter follows it.

I'll take an example from the Spotify API: https://developer.spotify.com/web-api/get-playlist/:

Get a Playlist

Get a playlist owned by a Spotify user.

Endpoint

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

Request Parameters

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

In that API endpoint, you specify that you are looking for a users object with user_id of {user_id}, and a playlists object (within that users object) with the playlist_id of {playlist_id}.

Some RESTful services allow combination flags on parameters.

Take the Stack Exchange API, for example. You can fetch multiple questions or answers by separating them with semicolons, and it will essentially filter to just those questions or answers.

If we analyze this endpoint (/questions/{ids}/answers), you'll see that it specifies:

Gets the answers to a set of questions identified in id.

This method is most useful if you have a set of interesting questions, and you wish to obtain all of their answers at once or if you are polling for new or updates answers (in conjunction with sort=activity).

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects.

The sorts accepted by this method operate on the follow fields of the answer object:

This is also a good example of an API that allows additional GET requests to filter/sort the results even further.

Example of usage: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow

Now, if we do the same with the /answers/{ids} endpoint, we can come up with something along the lines of: https://api.stackexchange.com/2.2/answers/30582379;30581997;30581789;30581628?order=desc&sort=activity&site=stackoverflow. This pulls the four specified answers for us.

We can combine even more, for example, with the SE API and include filters to restrict the fields returned: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow&filter=!)V)P2Uyugvm. (See this link to /2.2/filters for an explanation of that filter parameter.)

---

SOAP-based Services

Enter SOAP (Simple Object Access Protocol), which was the predecessor to REST. SOAP solved this problem by sending messages back and forth. They use XML (though you could build a SOAP-based service without it, similarly to being able to build a RESTful service without JSON) to exchange a message, whereby the server has no initial indication of what to do.

SOAP-based services solve this issue in a manner that is agnostic of transport medium. The server and client need not use HTTP, or even TCP at all. They just need to use the same, or compatible transport mediums. In fact, you could think of the modern-day corporate environment as a SOAP-based service. When you need to get new supplies, you put in a requisition to your office manager, who then responds with a message. Upon receiving the initial requisition, your manager has no idea if it is permitted or not. They have to read the rest of the requisition in order to determine whether it is a valid request or if it is invalid.

SOAP was designed around RPCs (Remote-Procedure Calls), many firewalls block these. So, as a result, SOAP was modified to work over HTTP. It was designed to integrate vastly different technologies.

Because SOAP is designed around messages, it is a much more verbose service. It is generally easier to represent compound actions in SOAP services. That is to say, if you are requesting objects based on many criteria (instead of just one) SOAP tends to have better interface for this.

SOAP-based Filtering

SOAP-based services filter with additional fields in the RPC. How these fields are combined is up to the provider.

I'll take an example from the Global Weather API: http://www.webservicex.net/globalweather.asmx?op=GetWeather:

GetWeather

Get weather report for all major cities around the world.

Test

To test the operation using the HTTP POST protocol, click the 'Invoke' button.

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

If you specify, for example, "Blanding" and "United States" you will see the generated XML looks like the following:

<?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>

This would be submitted (for an HTTP SOAP request) as a POST-based call to http://www.webservicex.net/globalweather.asmx/GetWeather.

---

Back to the original question:

Can a SOAP-based webservice be RESTful?

This was your original question, and I believe it stands to reason that it cannot, based on the information I have provided. These two services are mutually-exclusive. REST intends to solve the issue with the exchange of headers that indicate intent, and message bodies that indicate purpose. SOAP intends to solve the issue with the exchange of messages that indicate intent and purpose.

Will it be a violation of REST architecture to use HTTP POST to get data from a resource? Yes. The RESTful service architecture is designed to use the term POST to represent a specific action. Each HTTP verb in REST represents what that action intends to do.

As I said in the comments on the initial question:

You can use HTTP POST to get the data, but it's not a RESTful service then, as the HTTP verb has no meaning. RESTful services are RESTful because the verb indicates the action.

---

What do I choose, SOAP or REST?

This part exists primarily for future readers.

Both protocols have advantages and disadvantages, and you should choose which protocol you are using based on the requirements of the problem. Instructing you on how to accomplish that is beyond the scope of this question and answer. That said, there are three things to consider: know your project, know your requirements, and most of all, correctly document it for your audience.

这篇关于SOAP和REST Web服务之间有什么区别?SOAP可以是RESTful的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！