REST如何使用SOAP作为协议？

REST是一种体系结构样式，如果正确应用，则可以使客户端与服务器解耦，这与Web浏览器类似，Web浏览器没有特别耦合到任何特定的Web服务器，但耦合到它们交换的媒体类型。另一方面，SOAP是一种协议，该协议在W3C建议中详细描述了预期的语法及其语义，该协议通常被称为将客户端与实现耦合在一起，因为合同通常预先生成为实际针对实际客户端进行编译并与之交互的存根类。 。如果服务接口由于某些原因而发生更改，则较早的实现将肯定会中断。

尽管REST本身不是协议本身（它没有定义要交换的消息的语法或顺序），但是它仍然需要根据协议标准概述的规则使用其他协议。多数情况下，REST API都会将其自身限制为HTTP。根据Roy Fielding的说法，遵循RESTful准则的应用程序不应依赖于单个通信协议，而应支持多个通信协议。这可以是HTTP，SMTP，（S）FTP和其他协议，例如SOAP。

REST施加的主要限制之一是，API必须是超文本驱动的，并支持客户与服务进行交互的冒险。这通常与向客户端提供进一步的URI进行交互，从而允许客户端采取进一步的操作来遵循某个目标。URI的形式不是重要的部分（是否包含动词或与RESTful客户端无关），因为客户端不应该分析URI本身，因此不应该推论某些语义，而应使用伴随的关系名称。如果实际URI由于任何原因而更改，则RESTful客户端仍将能够通过利用关系名称与API本身进行交互，而不必解释URI本身。

除此之外，服务器和客户端可以同意的媒体类型概述了客户端可以采取的进一步操作的知识。媒体类型包含一组处理指令，这些指令告诉接收者如何解释接收到的数据。

REST API响应因此可以包含到客户端可以调用的SOAP端点的链接。内容协商可以告诉客户端需要媒体类型application/soap+xml，这可以为客户端提供线索，表明SOAP 1.2服务位于URI位置。由于SOAP服务通常是通过普通方式HTTP POST调用的，因此服务方法本身的调用并不是真正的问题，这是客户端如何知道要发送的内容以及如何对其进行实际格式化的方式。

尽管SOAP客户端通常是根据存根类编译的，这些存根类实现了通过WSDL取消的特定合同，但是可以通过解释WSDL合同并将必要的信息混合在一起来动态调用服务本身，从而将格式正确的SOAP消息发送给各自的端点。我在这里看到的问题是，虽然可以在URI中轻松定义SOAP服务端点和调用方法，但是通过在该URI ?wsdl的末尾附加a并不一定可以使用合同描述（WSDL），并且因此需要以其他方式指定WSDL合同。

无论是HTML还是在JSON HAL定义链接指示客户端使用某些WSDL合约生成一个适当的消息内容propper属性。不知道profiles是否可以实际填补这个位置。我还不知道目前还有其他媒体类型或协议。因此，这将需要某种隐式（或Fielding称其为“带外”）信息集成到客户端本身，如果某人以不同的方式发布SOAP服务或其合同，则增加了失败的可能性进一步查找该WSDL。

总而言之，尽管REST通常应该能够与SOAP配合使用，但仍需要完成某些工作以支持客户端动态组合向服务IMO发出有效请求所需的必需信息。当提供这种支持时，我看不到通过RESTful客户端发送SOAP消息的主要问题。但是，我还没有看到任何实际的尝试从（真实的）RESTful API调用SOAP的尝试（尽管实际上它们还很稀疏）。通常两者是分开的。尽管已经尝试描述类似于SOAP的REST服务（提示：WADL），但这种方法除了RESTful以外，什么都没有。