来自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。
来自维基百科页面http://en.wikipedia.org/wiki/Representational_state_transfer
RESTful系统通常（但并非总是）通过超文本传输协议与Web浏览器使用的相同HTTP谓词（GET，POST，PUT，DELETE等）进行通信，以检索网页并将数据发送到远程服务器。
但使用HTTP POST从资源中获取数据会违反REST架构吗？ 换句话说，基于SOAP的Web服务可以是RESTful吗？
RESTful和基于SOAP的Web服务之间是否存在其他差异？
答案 0 :(得分：26)
我发布这个作为答案，因为评论不够。以下是我想要总结的内容。
首先，我们将从这两个引用开始：
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想通过以下说法开始这篇文章：
SOAP 和 REST 都旨在解决以下问题：两个不同的应用程序，程序或设备如何在两者之间交换和共享数据彼此之间是否有可扩展且易于理解的方式？
按设计 RESTful （重新表示 S tate T 转移）服务使用HTTP和HTTP动词（GET，POST，PUT，DELETE）来表示意图。这些动词非常清楚向用户表明使用它们时会发生什么。服务器可以使用它们来做出抢先决定。也就是说，它可以在动作准备好之前很久做出决定。
考虑到这一点，您必须从用户插入服务帐户访问一小部分数据。哪个更容易，GET endpoint/users/account/id请求或POST endpoint/users/account请求的正文为id？根据 REST 的定义，POST请求违反了 REST 所暗示的基本协议。那就是：服务器应该在数据到达之前知道用户对它的意图。这是 REST 试图保证的基本基础。< / p>
这个事实，不，这个基本要求允许 RESTful 通信表明客户端在客户端开始发送数据之前有什么意图。这允许服务器在消息到达之前很久就接受和拒绝消息，从而减少处理负荷。
REST 的另一个方面（特别是 Twitter ， Facebook 和 Google API）： RESTful 服务，HTTP的焦点和授权，可以利用HTTP响应标头。也就是说，如果客户端不被允许访问，他们可能会使用HTTP 403 Forbidden消息进行响应。 基于SOAP的服务可能不会。结果消息必须表明这样的结果。
RESTful 服务倾向于将HTTP verbs（或动作）与名词（或实体/对象）相关联。一般来说，多元和单一性意味着更多关于行动。即GET RootEndpoint/Employees预计将返回所有员工（或至少是符合特定条件的大型群组。）而GET RootEndpoint/Employee/12预计会返回仅一个员工。 （通常，ID为12的员工。）
RESTful 服务在HTTP verb（GET，POST，PUT，{之间建立直接关联 {1}}）和动作。这是两者之间联系的目的：没有什么特别的东西需要添加到消息体中以指示用户打算做什么。 （我将继续强调这一点。）
REST 完全是为DELETE设计的。并且非常擅长于它的工作。
一般来说，要过滤HTTP服务请求，您需要包含多个网址段，每个网段都会指示跟随它的参数。
我将从Spotify API中获取示例：REST：
获取播放列表
获取Spotify用户拥有的播放列表。
端点
https://developer.spotify.com/web-api/get-playlist/请求参数
GET https://api.spotify.com/v1/users/{user_id}/playlists/{playlist_id}
在该API端点中，您指定要查找的+---------------------------------------------------+
| Path parameter | Value |
+---------------------------------------------------+
| user_id | The user's Spotify user ID. |
| playlist_id | The Spotify ID for the playlist. |
+---------------------------------------------------+
users user_id对象{user_id}和playlists对象（在users内{object}} playlist_id {playlist_id}。
某些RESTful服务允许在参数上使用组合标记。
以Stack Exchange API为例。您可以通过用分号分隔来获取多个问题或答案，它基本上会过滤到那些问题或答案。
如果我们分析this endpoint (/questions/{ids}/answers)，您会看到它指定：
获取id。
中标识的一组问题的答案如果您有一组有趣的问题，并且您希望立即获得所有答案，或者您正在轮询新的答案或更新答案（与sort = activity一起使用），则此方法最有用。
{ids}最多可以包含100个以分号分隔的ID，以便在问题对象上以编程方式查找question_id。此方法接受的排序操作在答案对象的以下字段中：
这也是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 （ S 实施 O bject A ccess P rotocol） ，这是 REST 的前身。 SOAP 通过来回发送消息解决了这个问题。他们使用XML（虽然您可以在没有它的情况下构建基于SOAP的服务，类似于能够在没有JSON的情况下构建 RESTful 服务交换消息，服务器没有初始指示应该做什么。
基于SOAP的服务以与传输介质无关的方式解决此问题。服务器和客户端无需使用HTTP，甚至根本不需要使用TCP。他们只需要使用相同或兼容的传输介质。实际上，您可以将现代企业环境视为基于SOAP的服务。当您需要获得新的供应品时，您将申请单输入您的办公室经理，然后他们会回复一条消息。收到初始请购单后，如果允许，您的经理不知道。他们必须阅读申请的其余部分，以确定它是有效请求还是无效。
SOAP 是围绕RPCs（远程过程调用）设计的，许多防火墙阻止了这些。因此， SOAP 被修改为在HTTP上工作。它旨在集成截然不同的技术。
因为 SOAP 是围绕消息设计的，所以它是一个很多更详细的服务。在 SOAP 服务中表示复合操作通常更容易。也就是说，如果您根据许多条件请求objects（而不只是一个） SOAP 往往会为此提供更好的界面。
基于SOAP的服务使用RPC中的其他字段进行过滤。这些字段的组合方式取决于提供者。
我将从全球天气API中获取示例：http://www.webservicex.net/globalweather.asmx?op=GetWeather：
的GetWeather
获取全球所有主要城市的天气报告。
测试
要使用HTTP POST协议测试操作，请单击“调用”＃39;按钮。
+---------------------------------------------------+ | Parameter | Value | +---------------------------------------------------+ | CityName: | | | CountryName: | | +---------------------------------------------------+
例如，如果您指定＆＃34; Blanding＆＃34;和＃34;美国＆＃34;您将看到生成的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请求）。
回到原来的问题：
这是你原来的问题，而且我认为根据我提供的信息，它是不可能的。这两项服务是互斥的。 REST 打算通过交换表示意图的headers以及表示目的的message bodies解决问题。 SOAP 打算通过messages的交换来解决问题，以表明意图和目的。
使用HTTP POST从资源获取数据会违反REST架构吗？是的。 RESTful 服务架构旨在使用术语POST来表示特定操作。 REST 中的每个HTTP verb代表该行动打算做什么。
正如我在最初问题的评论中所说：
您可以使用
HTTP POST来获取数据，但它不是 RESTful 服务，因为HTTP verb没有任何意义。 RESTful 服务 RESTful ，因为动词表示操作。
此部分主要面向未来的读者。
两种协议都有优点和缺点，您应根据问题的要求选择使用的协议。指导您如何实现这一点超出了这个问题和答案的范围。也就是说，有三件事需要考虑：了解您的项目，了解您的要求，最重要的是，正确地为您的受众记录了这些内容。
答案 1 :(得分：3)
REST使用HTTP动词来表达您要完成的操作。
A＆＃34; GET＆＃34;请求是要求服务在某个位置返回该项目。
A＆＃34; POST＆＃34;请求是要求服务在某个位置创建一个新实体（可能会在后台持久保存到DB）。
A＆＃34; PUT＆＃34;请求要求服务更新某个位置的现有实体。
A＆＃34; DELETE＆＃34;请求要求服务删除某个位置的现有实体。
所以不，你不能真正使用＆＃34; POST＆＃34;像'＆＃34; GET＆＃34;并称自己为REST API。你的消费者会对此感到困惑。
答案 2 :(得分：2)
从概念上讲，服务非常不同。
SOAP是关于远程过程调用（RPC）的，这意味着它旨在远程调用方法。客户端上的服务器方法的代理必须与服务器保持同步。 WSDL通常用于使模型保持同步。
SOAP还忽略了许多HTTP功能。正如您所提到的，它使用POST方法处理所有事情。它还以专有的XML数据格式包装数据。
REST使用URL来引用资源。资源表示可以是任何格式（json，xml，csv，binary，...），并且可以利用HTTP内容协商（Accept *标头）。 HTTP方法很好地映射到CRUD方法。
真正的REST服务必须使用超媒体驱动的数据格式（HAL，JSON集合......或供应商自定义）。它提供了从单个固定URL发现指向相关资源的链接的功能。
http://en.wikipedia.org/wiki/HATEOAS
我不知道同一服务（单一合同）如何满足所有标准。
答案 3 :(得分：-1)
是的，存在差异。
服务中的端点彼此不同。
您可以使用所有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>