c# - SOAP 和 REST 网络服务有什么区别？ SOAP 可以是 RESTful 吗？

Question

来自 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 系统通常但并非总是通过超文本传输​​协议(protocol)与 Web 浏览器使用的相同 HTTP 动词(GET、POST、PUT、DELETE 等)进行通信，以检索网页并将数据发送到远程服务器。

但是使用 HTTP POST 从资源中获取数据是否违反 REST 架构 ?
换句话说，基于 SOAP 的网络服务可以是 RESTful 的吗？

RESTful 和基于 SOAP 的网络服务之间还有其他区别吗？

Answer 1

简介
我将此作为答案发布，因为评论是不够的。这是我想为您总结的内容。
首先，我们将从这两个引用开始:
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想通过以下几点开始这篇文章:
SOAP 和 REST 都旨在解决以下问题:两个不同的应用程序、程序或设备如何以可扩展且易于理解的方式相互交换和共享数据？

RESTful 服务
按照设计的RESTful (重新表象小号泰特牛逼转让(BOT))服务使用HTTP和HTTP动词(GET，POST，PUT，DELETE)来表示的意图。这些动词非常清楚地向用户表明使用它们时会发生什么。服务器可以使用它们来做出先发制人的决定。也就是说，它可以在行动准备好发生之前很久就做出决定。
考虑到这一点，您必须从用户 插入服务 帐户访问少量数据。 GET endpoint/users/account/id 请求或具有 POST endpoint/users/account 主体的 id 请求哪个更容易？根据 REST 的定义，POST 请求违反了 REST 暗示的基本协议(protocol)。也就是说:在数据到达之前，服务器应该知道用户对它有什么意图。这是 REST 试图保证的基本原理。
这个事实，不，这个基本的，要求 RESTful 通信被允许在客户端开始发送数据之前表明客户端有什么意图。这允许服务器在消息到达之前很久就接受和拒绝消息，从而减少处理负载。
REST (尤其是与Twitter的 ， Facebook的和谷歌的API)的另一个方面: REST风格服务，重点和任务上HTTP，可以采取HTTP响应头的优势。也就是说，如果不允许客户端访问，它们可能会以 HTTP 403 Forbidden 消息响应。 基于 SOAP 的 服务可能不会。结果消息必须表明这样的结果。
RESTful 服务倾向于将 HTTP verbs(或 Action )与名词(或实体/对象)联系起来。一般来说，复数和单数意味着更多关于 Action 的信息。即GET RootEndpoint/Employees 预计会返回 所有 名员工(或至少是一个符合特定条件的大组。)而 GET RootEndpoint/Employee/12 预计仅返回 一名 员工。 (通常，ID 为 12 的员工。)
RESTful 服务在 HTTP verb ( GET , POST , PUT , DELETE ) 和 Action 之间建立直接关联。这就是两者之间联系的目的:没有什么特别需要添加到消息正文中来指示用户打算做什么。 (我将在整个过程中继续强调这一点。)
REST 完全是为 HTTP 设计的。它是 非常 擅长它的工作。
RESTful 过滤
一般来说，要过滤 REST 服务请求，您将包含多个 URL 段，每个段指示其后面的参数。
我将从 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. |
+---------------------------------------------------+

在该 API 端点中，您指定要查找具有 users 的 user_id 的 {user_id} 对象和具有 playlists 的 users 的 playlist_id 对象(在该 {playlist_id} 对象内)。
一些 RESTful 服务允许在参数上使用组合标志。
以 Stack Exchange API 为例。您可以通过用分号分隔多个问题或答案来获取多个问题或答案，它本质上将仅过滤到这些问题或答案。
如果我们分析 this endpoint (/questions/{ids}/answers) ，您会看到它指定:

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:

这也是 API 的一个很好的例子，它允许额外的 GET 请求进一步过滤/排序结果。
用法示例:https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=stackoverflow现在，如果我们对 /answers/{ids} endpoint 做同样的事情，我们可以想出一些类似的东西: 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 。 (有关该 filter 参数的说明，请参阅 this link to /2.2/filters。)

基于 SOAP 的服务
输入 SOAP (小号 imple ö bject 甲 CCESS P rotocol)，这是前身 REST 。 SOAP 通过来回发送消息解决了这个问题。他们使用 XML(尽管您可以在没有它的情况下构建 SOAP-based 服务，类似于能够在没有 JSON 的情况下构建 RESTful 服务，从而指示服务器没有进行交换的初始消息)
基于 SOAP 的 服务以一种与传输介质无关的方式解决了这个问题。服务器和客户端不需要使用 HTTP ，甚至根本不需要 TCP 。他们只需要使用相同或兼容的传输介质。事实上，您可以将现代企业环境视为 基于 SOAP 的 服务。当您需要获得新的供应品时，您可以向您的办公室经理提出申请，然后他会回复一条消息。收到初始申请后，您的经理不知道是否允许。他们必须阅读申请的其余部分，以确定它是有效的请求还是无效的请求。
SOAP 是围绕 RPCs(远程程序调用)设计的，许多防火墙阻止了这些。因此，结果是 SOAP 被修改为处理 HTTP 。它旨在集成截然不同的技术。
因为 SOAP 是围绕消息设计的，所以它是一个更加冗长的服务。在 SOAP 服务中表示复合操作通常更容易。也就是说，如果您根据 许多 标准(而不是只有一个)请求 objects SOAP 往往有更好的接口(interface)。
基于 SOAP 的过滤
基于 SOAP 的服务使用 RPC 中的附加字段进行过滤。如何组合这些字段取决于提供者。
我将举一个来自 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:   |                                  |
+---------------------------------------------------+

例如，如果您指定“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://www.webservicex.net/globalweather.asmx/GetWeather 的基于 POST 的调用提交(对于 HTTP SOAP 请求)。

回到最初的问题:
基于 SOAP 的网络服务可以是 RESTful 吗？
这是您最初的问题，根据我提供的信息，我相信它不能。这两项服务是互斥的。 REST 旨在通过表示意图的 headers 和表示目的的 message bodies 的交换来解决问题。 SOAP 旨在解决指示意图和目的的 messages 交换问题。
使用 HTTP POST 从资源中获取数据是否违反 REST 架构？ 是的。 RESTful 服务架构旨在使用术语 POST 来表示特定操作。 REST 中的每个 HTTP verb 表示该操作打算做什么。
正如我在对最初问题的评论中所说:

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.

我该选择什么，SOAP 还是 REST？
这部分主要是为 future 的读者而存在的。
两种协议(protocol)各有优缺点，您应该根据问题的要求选择使用哪种协议(protocol)。指导您如何实现这一点超出了本问答的范围。也就是说，需要考虑三件事:了解您的项目，了解您的要求，最重要的是，为您的观众正确记录它。