SOAP 和 REST 网络服务之间有什么区别?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 缓存和其他功能(例如 Conditional GET)来帮助扩展服务.其中许多技术不能与 SOAP 一起使用，因为 SOAP 仅通过 HTTP 使用 POST.
来自维基百科页面http://en.wikipedia.org/wiki/Representational_state_transfer
RESTful 系统通常(但不总是)通过超文本传输协议与 Web 浏览器使用的相同 HTTP 动词(GET、POST、PUT、DELETE 等)进行通信，以检索网页并将数据发送到远程服务器.[
但是使用 HTTP POST 从资源中获取数据是否会违反 REST 架构?换句话说，基于 SOAP 的网络服务可以是 RESTful 的吗?
RESTful 和基于 SOAP 的网络服务之间还有其他区别吗?
简介
我将此作为答案发布，因为评论是不够的.这是我想为您总结的内容.
首先，我们将从以下两个参考开始:
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想通过以下内容开始这篇文章:
SOAP 和 REST 都旨在解决以下问题:两个不同的应用程序、程序或设备如何在它们之间交换和共享数据?相互之间，以一种可扩展且易于理解的方式?
RESTful 服务
By design RESTful(重新展示性State T传输)服务使用 HTTP 和 HTTP 动词(GET、POST、PUT、>DELETE) 表示意图.这些动词非常清楚向用户表明使用它们时会发生什么.服务器可以使用它们来做出抢占决策.也就是说，它可以在行动准备好开始之前很久做出决定.
考虑到这一点，您必须从用户插入服务帐户访问少量数据.哪个更简单，GET endpoint/users/account/id 请求，或具有 id 正文的 POST endpoint/users/account 请求>?根据REST 的定义，POST 请求违反了REST 暗示的基本协议.也就是说:在数据到达之前，服务器应该知道用户对它有什么意图.这是 REST 试图保证的基本原理.
这个事实，不，这个基本原理，要求允许 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 用户拥有的播放列表.
端点
GET https://api.spotify.com/v1/users/{user_id}/playlists/{playlist_id}请求参数
+---------------------------------------------------+|路径参数 |价值 |+---------------------------------------------------+|用户 ID |用户的 Spotify 用户 ID.||playlist_id |播放列表的 Spotify ID.|+---------------------------------------------------+在该 API 端点中，您指定要查找具有 user_id 的 {user_id} 和 users 对象>playlists 对象(在那个 users 对象内)，带有 {playlist_id} 的 playlist_id.
某些 RESTful 服务允许在参数上使用组合标志.
以 Stack Exchange API 为例.您可以通过用分号分隔多个问题或答案来获取多个问题或答案，它实际上将过滤到仅这些问题或答案.
如果我们分析这个端点 (/questions/{ids}/answers)，你会看到它指定:
<块引用>获取 id 中标识的一组问题的答案.
如果您有一组有趣的问题，并且您希望一次获得他们的所有答案，或者您正在轮询新的或更新的答案(结合 sort=activity)，则此方法最有用.
{ids} 最多可以包含 100 个分号分隔的 id，要以编程方式查找 id，请在问题对象上查找 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(Simple Object A访问P协议)，它是 REST 的前身.SOAP 通过来回发送消息解决了这个问题.他们使用 XML(尽管您可以在没有它的情况下构建 基于 SOAP 的 服务，类似于无需 即可构建RESTful 服务JSON) 来交换消息，由此服务器没有初始指示要做什么.
基于 SOAP 的服务以一种与传输介质无关的方式解决了这个问题.服务器和客户端根本不需要使用HTTP，甚至TCP.他们只需要使用相同或兼容的传输媒介.事实上，您可以将现代企业环境视为一种基于 SOAP 的服务.当您需要获得新的供应品时，您可以向您的办公室经理提交申请，然后他会回复一条消息.收到初始申请后，您的经理不知道是否允许.他们必须阅读其余的申请，以确定它是有效的请求还是无效的请求.
SOAP 是围绕 RPCs(远程过程调用)设计的，许多防火墙阻止了这些.因此，结果是，SOAP 被修改为在 HTTP 上工作.它旨在集成截然不同的技术.
因为 SOAP 是围绕消息设计的，所以它是一个 更加冗长的服务.在 SOAP 服务中表示复合操作通常更容易.也就是说，如果您根据许多标准(而不是只有一个)请求对象，SOAP 往往会为此提供更好的接口.
基于 SOAP 的过滤
基于 SOAP 的服务在 RPC 中使用附加字段进行过滤.如何组合这些字段取决于提供者.
我将以全球天气 API 为例:http://www.webservicex.net/globalweather.asmx?op=GetWeather:
<块引用>获取天气
获取全球所有主要城市的天气报告.
测试
要使用 HTTP POST 协议测试操作，请单击调用"按钮.
+---------------------------------------------------+|参数 |价值 |+---------------------------------------------------+|城市名称: |||国名: ||+---------------------------------------------------+例如，如果您指定Blanding"和美国"您将看到生成的 XML 如下所示:
<块引用><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>美国</CountryName></获取天气></soap12:Body></soap12:信封>这将作为对 http://www.webservicex.net/globalweather.asmx/GetWeather 的基于 POST 的调用提交(对于 HTTP SOAP 请求).
回到最初的问题:
基于 SOAP 的网络服务可以是 RESTful 吗?
这是您最初的问题，根据我提供的信息，我相信它不能.这两个服务是互斥的. REST 旨在通过指示意图的 headers 和 消息正文的交换来解决问题 表示目的.SOAP 旨在解决指示意图和目的的消息 交换的问题.
使用 HTTP POST 从资源中获取数据是否违反 REST 架构?是的.RESTful 服务架构旨在使用术语POST 来表示特定操作. HTTP 动词 中的每个HTTP 动词strong>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 forquestion_idon 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 POSTto get the data, but it's not a RESTful service then, as theHTTP verbhas 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 网络服务之间有什么区别?SOAP 可以是 RESTful 吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
