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 and https://msdn.microsoft.com/en-us/magazine/dd942839.aspx
我明白
当 RESTful 端点使用 HTTP 请求数据时，使用的 HTTP 动词是 GET。
使用 REST 意味着您可以利用 HTTP 缓存和其他有助于扩展服务的功能，如条件 GET。其中许多技术不能用于 SOAP，因为 SOAP POST 仅在 HTTP 上使用。
来自维基百科页面http://en.wikipedia.org/wiki/Representational_state_transfer
RESTful 系统通常（但并非总是）通过超文本传输协议与 Web 浏览器使用的相同 HTTP 动词（GET、POST、PUT、DELETE 等）进行通信以检索网页并将数据发送到远程服务器。[
但是使用 HTTP POST 从资源 获取数据是否会违反 REST 架构？
换句话说，基于 SOAP 的网络服务可以 RESTful?
RESTful 和基于 SOAP 的网络服务之间还有其他区别吗？
REST 使用 HTTP 动词来阐明您要完成的操作。
"GET" 请求要求服务 return 某个位置的项目。
一个 "POST" 请求要求服务在一个位置创建一个新实体（这可能会在幕后持久保存到数据库中）。
"PUT" 请求要求服务更新某个位置的现有实体。
"DELETE" 请求要求服务删除某个位置的现有实体。
所以不，您不能真正将 "POST" 用于 "GET" 之类的东西，并且仍然称自己为 REST API。您的消费者会对此感到困惑。
是的，有区别。
服务中的端点将彼此不同。
您可以毫无问题地为您的 RESTful 服务使用所有 HTTP 动词。
在您的 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>
概念上，服务有很大不同。
SOAP 是关于远程过程调用 (RPC) 的，这意味着它旨在远程调用方法。客户端上服务器方法的代理必须与服务器保持同步。 WSDL 通常用于保持模型同步。
SOAP 也忽略了很多 HTTP 特性。正如您提到的，它对所有内容都使用 POST 方法。它还以专有的 XML 数据格式包装数据。
REST 使用 URLs 来引用资源。资源表示可以是任何格式（json、xml、csv、二进制...）并且可以利用 HTTP 内容协商（Accept* headers）。 HTTP 方法很好地映射到 CRUD 方法。
真正的 REST 服务必须使用超媒体驱动的数据格式（HAL、JSON collection、...或供应商自定义）。它提供了从单个固定 URL.
发现关联资源链接的能力。
http://en.wikipedia.org/wiki/HATEOAS
我看不出同一项服务（单一合同）如何满足所有这些标准。
简介
我post将此作为答案，因为评论是不够的。下面就是我想为大家总结的。
首先，我们将从这两个参考文献开始：
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想通过下面的话开始post：
SOAP 和 REST 都是为了解决以下问题而设计的：两个 disparate 应用程序、程序或设备以可扩展和 easily-understood 的方式相互交换和共享数据？
RESTful 服务
按设计RESTful（Re演示 State Transfer) 服务使用 HTTP 和 HTTP 动词 (GET, POST, PUT, DELETE) 来表示意图。这些动词非常清楚地 向用户表明了使用它们时会发生什么。服务器可以使用它们做出先发制人 决定。也就是说，它可以在 行动准备好发生之前 很久就做出决定。
考虑到这一点，您必须从用户 Insert Service 帐户访问少量数据。 GET endpoint/users/account/id 请求或具有 id 的 body 的 POST endpoint/users/account 请求哪个更容易？根据 REST 的定义，POST 请求违反了 REST 暗示的基本协议。即：服务器应该知道，在数据到达之前，用户有什么意图。这是REST[=238=的基本原理] 尽力保证。
这个事实，不，这个基本原理，要求允许RESTful通信，以表明客户端在开始发送数据之前有什么意图。这允许服务器在消息到达之前很久就接受和拒绝消息，从而减少处理负载。
REST 的另一个方面（尤其是 Twitter、Facebook 和 Google APIs): RESTful 服务，重点和任务是 HTTP，可以利用 HTTP 响应 headers。也就是说，如果不允许客户端访问，他们可能会用 HTTP 403 Forbidden 消息进行响应。 SOAP-based服务未必。结果消息必须指示这样的结果。
RESTful服务倾向于将HTTP verbs（或动作）与名词（或entities/objects）联系起来。一般来说，复数和单数暗示更多关于行动。 IE。 GET RootEndpoint/Employees 预计 return 所有 员工（或至少一大群符合特定条件的员工。）而 GET RootEndpoint/Employee/12 预计 return 只有一个 员工。 （通常是 ID 为 12 的员工。）
RESTful 服务在 HTTP verb (GET, POST, PUT, DELETE) 和 动作。 这就是两者之间的联系的目的：没有什么特别需要添加到消息 body 表明 用户打算做什么。（我将继续强调这一点。）
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 object user_id of {user_id}，以及 playlists object（在 users object 内）与 {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 请求 filter/sort 结果更进一步。
用法示例：https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=Whosebug
现在，如果我们对 /answers/{ids} endpoint 做同样的事情，我们可以得出类似于：https://api.stackexchange.com/2.2/answers/30582379;30581997;30581789;30581628?order=desc&sort=activity&site=Whosebug 的结果。这为我们提取了四个指定的答案。
我们可以结合更多，例如，与 SE API 并包括过滤器来限制字段 returned: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=Whosebug&filter=!)V)P2Uyugvm。 （有关 filter 参数的解释，请参阅 this link to /2.2/filters。）
SOAP-based 服务
输入SOAP (Simple Object Access Protocol)，它是 REST 的前身。 SOAP 通过来回发送消息解决了这个问题。他们使用 XML（虽然你可以构建一个 [=189=SOAP-based 没有它的服务，类似于能够在没有 JSON 的情况下构建 RESTful 服务来交换消息，从而服务器没有关于要做什么的初始指示。
SOAP-based 服务以一种与传输介质无关的方式解决了这个问题。服务器和客户端不需要使用 HTTP，甚至根本不需要 TCP。他们只需要使用相同或兼容的传输介质。事实上，您可以将 modern-day 企业环境视为 SOAP-based 服务。当您需要购买新用品时，您可以向您的办公室经理提交 申请，然后他会回复一条消息。收到初始申请后，您的经理不知道是否允许。他们必须阅读请购单的其余部分，以确定它是有效请求还是无效。
SOAP 是围绕 RPCs（Remote-Procedure 调用）设计的，许多防火墙会阻止这些。因此，SOAP 被修改为可以在 HTTP 上工作。它旨在集成 截然不同的 技术。
因为 SOAP 是围绕消息设计的，所以它是一个 much 更冗长的服务。在 SOAP 服务中表示 复合操作 通常更容易。也就是说，如果您请求 objects 基于 许多 标准（而不是只有一个） SOAP 往往有更好的接口为此。
SOAP-based过滤
SOAP-based 服务过滤器在 RPC 中有附加字段。如何组合这些字段取决于提供者。
我将以全球天气为例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: | |
+---------------------------------------------------+
例如，如果您指定“布兰丁”和“美国”，您将看到生成的 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-based 调用提交（对于 HTTP SOAP 请求）
回到原题：
SOAP-based 网络服务可以 RESTful 吗？
这是你原来的问题，根据我提供的信息，我认为按理说不能。这两个服务是 mutually-exclusive. REST 旨在通过交换 headers 表示意图来解决问题，并且message bodies 表示目的。 SOAP 打算通过交换表明意图和目的的 messages 来解决问题。
使用 HTTP POST 从资源获取数据是否违反 REST 架构？ 是的。 RESTful 服务架构旨在使用术语 POST 来表示 特定操作。 每个 HTTP verb 在 REST 中表示 该操作 打算做什么。
正如我在第一个问题的评论中所说：
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？
这部分主要是为未来的读者准备的。
这两种协议各有优缺点，您应该根据问题的需求来选择您使用的协议。指导您如何实现这一目标超出了本问答的范围。也就是说，需要考虑三件事：了解您的项目、了解您的要求，最重要的是，正确记录为您的观众。
来自 MSDN 杂志 https://msdn.microsoft.com/en-us/magazine/dd315413.aspx and https://msdn.microsoft.com/en-us/magazine/dd942839.aspx 我明白
当 RESTful 端点使用 HTTP 请求数据时，使用的 HTTP 动词是 GET。
使用 REST 意味着您可以利用 HTTP 缓存和其他有助于扩展服务的功能，如条件 GET。其中许多技术不能用于 SOAP，因为 SOAP POST 仅在 HTTP 上使用。
来自维基百科页面http://en.wikipedia.org/wiki/Representational_state_transfer
RESTful 系统通常（但并非总是）通过超文本传输协议与 Web 浏览器使用的相同 HTTP 动词（GET、POST、PUT、DELETE 等）进行通信以检索网页并将数据发送到远程服务器。[
但是使用 HTTP POST 从资源 获取数据是否会违反 REST 架构？ 换句话说，基于 SOAP 的网络服务可以 RESTful?
RESTful 和基于 SOAP 的网络服务之间还有其他区别吗？
REST 使用 HTTP 动词来阐明您要完成的操作。
"GET" 请求要求服务 return 某个位置的项目。
一个 "POST" 请求要求服务在一个位置创建一个新实体（这可能会在幕后持久保存到数据库中）。
"PUT" 请求要求服务更新某个位置的现有实体。
"DELETE" 请求要求服务删除某个位置的现有实体。
所以不，您不能真正将 "POST" 用于 "GET" 之类的东西，并且仍然称自己为 REST API。您的消费者会对此感到困惑。
是的，有区别。
服务中的端点将彼此不同。
您可以毫无问题地为您的 RESTful 服务使用所有 HTTP 动词。
在您的 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>
概念上，服务有很大不同。
SOAP 是关于远程过程调用 (RPC) 的，这意味着它旨在远程调用方法。客户端上服务器方法的代理必须与服务器保持同步。 WSDL 通常用于保持模型同步。
SOAP 也忽略了很多 HTTP 特性。正如您提到的，它对所有内容都使用 POST 方法。它还以专有的 XML 数据格式包装数据。
REST 使用 URLs 来引用资源。资源表示可以是任何格式（json、xml、csv、二进制...）并且可以利用 HTTP 内容协商（Accept* headers）。 HTTP 方法很好地映射到 CRUD 方法。
真正的 REST 服务必须使用超媒体驱动的数据格式（HAL、JSON collection、...或供应商自定义）。它提供了从单个固定 URL.
发现关联资源链接的能力。http://en.wikipedia.org/wiki/HATEOAS
我看不出同一项服务（单一合同）如何满足所有这些标准。
简介
我post将此作为答案，因为评论是不够的。下面就是我想为大家总结的。
首先，我们将从这两个参考文献开始：
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想通过下面的话开始post：
SOAP 和 REST 都是为了解决以下问题而设计的：两个 disparate 应用程序、程序或设备以可扩展和 easily-understood 的方式相互交换和共享数据？
RESTful 服务
按设计RESTful（Re演示 State Transfer) 服务使用 HTTP 和 HTTP 动词 (GET, POST, PUT, DELETE) 来表示意图。这些动词非常清楚地 向用户表明了使用它们时会发生什么。服务器可以使用它们做出先发制人 决定。也就是说，它可以在 行动准备好发生之前 很久就做出决定。
考虑到这一点，您必须从用户 Insert Service 帐户访问少量数据。 GET endpoint/users/account/id 请求或具有 id 的 body 的 POST endpoint/users/account 请求哪个更容易？根据 REST 的定义，POST 请求违反了 REST 暗示的基本协议。即：服务器应该知道，在数据到达之前，用户有什么意图。这是REST[=238=的基本原理] 尽力保证。
这个事实，不，这个基本原理，要求允许RESTful通信，以表明客户端在开始发送数据之前有什么意图。这允许服务器在消息到达之前很久就接受和拒绝消息，从而减少处理负载。
REST 的另一个方面（尤其是 Twitter、Facebook 和 Google APIs): RESTful 服务，重点和任务是 HTTP，可以利用 HTTP 响应 headers。也就是说，如果不允许客户端访问，他们可能会用 HTTP 403 Forbidden 消息进行响应。 SOAP-based服务未必。结果消息必须指示这样的结果。
RESTful服务倾向于将HTTP verbs（或动作）与名词（或entities/objects）联系起来。一般来说，复数和单数暗示更多关于行动。 IE。 GET RootEndpoint/Employees 预计 return 所有 员工（或至少一大群符合特定条件的员工。）而 GET RootEndpoint/Employee/12 预计 return 只有一个 员工。 （通常是 ID 为 12 的员工。）
RESTful 服务在 HTTP verb (GET, POST, PUT, DELETE) 和 动作。 这就是两者之间的联系的目的：没有什么特别需要添加到消息 body 表明 用户打算做什么。（我将继续强调这一点。）
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 object user_id of {user_id}，以及 playlists object（在 users object 内）与 {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 forquestion_idon question objects.The sorts accepted by this method operate on the follow fields of the answer object:
这也是 API 的一个很好的例子，它允许额外的 GET 请求 filter/sort 结果更进一步。
用法示例：https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=Whosebug
现在，如果我们对 /answers/{ids} endpoint 做同样的事情，我们可以得出类似于：https://api.stackexchange.com/2.2/answers/30582379;30581997;30581789;30581628?order=desc&sort=activity&site=Whosebug 的结果。这为我们提取了四个指定的答案。
我们可以结合更多，例如，与 SE API 并包括过滤器来限制字段 returned: https://api.stackexchange.com/2.2/questions/30581530/answers?order=desc&sort=activity&site=Whosebug&filter=!)V)P2Uyugvm。 （有关 filter 参数的解释，请参阅 this link to /2.2/filters。）
SOAP-based 服务
输入SOAP (Simple Object Access Protocol)，它是 REST 的前身。 SOAP 通过来回发送消息解决了这个问题。他们使用 XML（虽然你可以构建一个 [=189=SOAP-based 没有它的服务，类似于能够在没有 JSON 的情况下构建 RESTful 服务来交换消息，从而服务器没有关于要做什么的初始指示。
SOAP-based 服务以一种与传输介质无关的方式解决了这个问题。服务器和客户端不需要使用 HTTP，甚至根本不需要 TCP。他们只需要使用相同或兼容的传输介质。事实上，您可以将 modern-day 企业环境视为 SOAP-based 服务。当您需要购买新用品时，您可以向您的办公室经理提交 申请，然后他会回复一条消息。收到初始申请后，您的经理不知道是否允许。他们必须阅读请购单的其余部分，以确定它是有效请求还是无效。
SOAP 是围绕 RPCs（Remote-Procedure 调用）设计的，许多防火墙会阻止这些。因此，SOAP 被修改为可以在 HTTP 上工作。它旨在集成 截然不同的 技术。
因为 SOAP 是围绕消息设计的，所以它是一个 much 更冗长的服务。在 SOAP 服务中表示 复合操作 通常更容易。也就是说，如果您请求 objects 基于 许多 标准（而不是只有一个） SOAP 往往有更好的接口为此。
SOAP-based过滤
SOAP-based 服务过滤器在 RPC 中有附加字段。如何组合这些字段取决于提供者。
我将以全球天气为例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: | | +---------------------------------------------------+
例如，如果您指定“布兰丁”和“美国”，您将看到生成的 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.
回到原题：
SOAP-based 网络服务可以 RESTful 吗？
这是你原来的问题，根据我提供的信息，我认为按理说不能。这两个服务是 mutually-exclusive. REST 旨在通过交换 headers 表示意图来解决问题，并且message bodies 表示目的。 SOAP 打算通过交换表明意图和目的的 messages 来解决问题。
使用 HTTP POST 从资源获取数据是否违反 REST 架构？ 是的。 RESTful 服务架构旨在使用术语 POST 来表示 特定操作。 每个 HTTP verb 在 REST 中表示 该操作 打算做什么。
正如我在第一个问题的评论中所说：
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.
我该选择什么，SOAP 还是 REST？
这部分主要是为未来的读者准备的。
这两种协议各有优缺点，您应该根据问题的需求来选择您使用的协议。指导您如何实现这一目标超出了本问答的范围。也就是说，需要考虑三件事：了解您的项目、了解您的要求，最重要的是，正确记录为您的观众。