简介
我将其发布为答案，因为 cmets 还不够。以下是我想为您总结的内容。
首先，我们将从这两个参考开始：
http://spf13.com/post/soap-vs-rest
http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
最后，我想以下面的话开始这篇文章：
SOAP 和 REST 都旨在解决以下问题：两个不同应用程序、程序或设备如何在它们之间交换和共享数据以可扩展且易于理解的方式相互连接？
RESTful 服务
按设计 RESTful（Re展示性S状态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 verbs（或动作）与名词（或实体/对象）相关联。一般来说，复数和单数更多地暗示了动作。 IE。 GET RootEndpoint/Employees 预计会返回所有 员工（或至少一个符合特定标准的大组）。而GET RootEndpoint/Employee/12 预计会返回一个 员工。 （通常是 ID 为 12 的员工。）
RESTful 服务在HTTP verb（GET、POST、PUT、DELETE）和 这就是两者之间联系的目的：没有什么特别的东西需要添加到消息正文中来指示用户打算做什么。（我将继续始终强调这一点。）
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}
请求参数
+---------------------------------------------------+
| Path parameter | Value |
+---------------------------------------------------+
| user_id | The user's Spotify user ID. |
| playlist_id | The Spotify ID for the playlist. |
+---------------------------------------------------+
在该 API 端点中，您指定要查找具有 user_id 的 {user_id} 的 users 对象和具有 playlist_id 的 playlists 对象（在该 users 对象内） 987654359@.
一些 RESTful 服务允许参数上的组合标志。
以 Stack Exchange API 为例。您可以通过用分号分隔多个问题或答案来获取多个问题或答案，它基本上会过滤到这些问题或答案。
如果我们分析this endpoint (/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} 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（Simple Object Access Protocol） ，它是 REST 的前身。 SOAP 通过来回发送消息解决了这个问题。他们使用XML（尽管您可以在没有它的情况下构建基于SOAP的服务，类似于在没有JSON的情况下构建RESTful服务）来交换消息，因此服务器没有初始指示要做什么。
基于 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:
获取天气
获取全球所有主要城市的天气报告。
测试
要使用 HTTP POST 协议测试操作，请单击“调用”按钮。
+---------------------------------------------------+
| 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 的 Web 服务可以是 RESTful 的吗？
这是您最初的问题，根据我提供的信息，我相信它不能。这两个服务互斥。 REST 打算通过交换表示意图的headers 和表示目的的message bodies 来解决问题。 SOAP 打算通过交换表明意图和目的的messages 来解决问题。
使用 HTTP POST 从资源中获取数据是否违反 REST 架构？ 是的。 RESTful 服务架构旨在使用术语POST 来表示特定操作。REST 中的每个HTTP verb 都表示该操作打算做什么。
正如我在最初的问题上所说的那样：
您可以使用HTTP POST 获取数据，但它不是RESTful 服务，因为HTTP verb 没有任何意义。 RESTful 服务是RESTful，因为动词 表示动作。
我该选择什么，SOAP 还是 REST？
这部分主要面向未来的读者。
这两种协议各有优缺点，应该根据问题的需求来选择使用哪种协议。指导您如何做到这一点超出了本问答的范围。也就是说，需要考虑三件事：了解您的项目，了解您的要求，最重要的是，为您的受众正确记录它。