在HTTP上运行的Soap服务是REST服务吗

我有一个通过http运行的Soap服务。这也是休息服务吗。什么样的标准使其成为REST服务。什么标准可以明确地将其排除在REST服务之外？有些帖子（例如）比较了REST和Soap，但似乎没有直接回答这个问题。我的答案是：是的，Soap服务在其功能级别上是一个http请求，它返回一个XML有效负载，其中状态不是由服务器维护的，因此是一个REST服务

适当的REST服务遵循Roy Fielding博士论文中阐述的架构指南。大多数人错误地使用术语“restapi”，而他们真正的意思是“httpapi”。无状态是API遵守REST体系结构指南的必要条件，但不是充分条件。

Fielding在其his中指出：

REST提供了一组体系结构约束，当作为一个整体应用时，这些约束强调组件交互的可伸缩性、接口的通用性、组件的独立部署以及中间组件，以减少交互延迟、加强安全性并封装遗留系统

如果你将上述属性与网络浏览进行比较，你会发现两者之间有很多相似之处，因为菲尔丁只是将使网络如此成功的概念应用到一个更广泛的领域，这也应该允许应用程序“上网冲浪”

为了正确地调用体系结构REST，它必须支持自描述性、可伸缩性和可缓存性，同时尊重并遵守底层传输协议概述的规则和语义，并强制使用定义良好的标准，如媒体类型、链接关系名称、HTTP操作、，URI标准

HATEOAS利用了服务的自我描述（或者说，我倾向于称之为“恨我们”，因为像我这样看到REST的好处的人总是要强调这个关键术语，因此它也以自己的术语结束）。通过HATEOAS，服务器为客户机提供所有可用的“操作”，客户机可以从客户机当前的“状态”中执行这些操作。这里的“操作”只是一个链接，带有一个附带的链接关系名称，客户端可以使用该名称推断何时最好地调用该URI。返回响应的媒体类型可能定义如何处理此类链接。HTML即表示，单击链接时会触发

GET

请求，并根据链接的参数将链接内容加载到当前窗格或新选项卡中。其他媒体类型可能定义相似或完全不同的内容。然而，这里的总格言是：继续探索。因此，REST体系结构中的交互模型设计得最好，而实际服务应该更像是一个Web站点方法，其中服务器正在向客户机发出指令，即请求的外观和发送到哪里（类似于HTML表单）

由于很多网页或多或少都是静态的，而且大多数请求都是以检索为中心的，因此Web严重依赖缓存。RESTAPI通常也是如此，因此这里对可缓存性有很强的要求，因为如果有适当的缓存，这可以显著减少服务器上的工作负载

通过使客户端状态远离服务器，这还允许将服务的新副本添加到位于负载平衡器或新区域后面的新服务器上，从而提高可伸缩性。客户端通常不关心从何处检索数据，因此服务器可能只返回指向克隆的URI，而不返回自身

另一方面，SOAP是RPC，与Java的远程方法调用（RMI）或CORBA类似，您有自己的接口定义语言（IDL）为您生成客户端存根代码，其中包含如何将某些对象转换为字节流以及如何通过调用某些方法的线路发送它们的实际逻辑

SOAP违反REST约束的原因很明显是缺乏在实际使用客户机之前必须具备的带外知识。SOAP消息通常作为

POST

操作进行交换，默认情况下不可缓存。某些HTTP头可用于允许中间服务器缓存响应，尽管SOAP没有使用这些头，因此缺乏对其的一般支持

为SOAP端点A开发的客户端很可能也无法与另一家公司运行的另一个SOAP端点B进行互操作。有人可能会说，Web客户机也不知道如何处理每种不同的媒体类型，但浏览器通常提供插件机制，将此类知识加载到客户机中。除此之外，媒体类型也是标准化的，至少它应该是标准化的，因此可以与许多服务器一起使用（想想闪存支持，即）。SOAP服务的另一个问题是，一旦WSDL定义中的任何内容发生更改，不知道更新的客户端很可能会停止使用该更新的服务，直到更新客户端代码以使用生成的存根类的最新版本

关于在SOAP中交换的XML格式：虽然从技术上讲，REST服务返回SOAP XML负载是可行的，但格式本身缺乏对HATEOAS的支持，这是必要的，而不是选项。客户机应该如何根据接收到的响应仅仅根据接收到的内容做出进一步的选择，而不事先了解API本身

我希望您可以看到，SOAP缺乏对缓存的支持，可能在可伸缩性方面存在问题，并导致客户端与实际API紧密耦合。SOAP消息信封/头/正文缺少HATEOAS支持，这也不允许客户端自由地探索API，从而适应服务器的变化aut