在阅读了很多关于Web服务的文章后，我开始知道REST可以使用SOAP作为协议。但我不是那样，在REST架构风格中SOAP的适用方式和位置如何？
答案 0 :(得分：1)
REST是一种体系结构样式，如果正确应用，则允许客户端与服务器分离，类似于不与任何特定Web服务器耦合的Web浏览器，而是与它们交换的媒体类型耦合。另一方面，SOAP是一种在a W3C recommendation中详细描述预期语法及其语义的协议，通常被称为将客户端耦合到实现，因为契约通常被预生成到实际客户端通常编译的存根类中。与...互动。如果服务接口由于某些原因而发生变化，那么旧的实现将会有一定的确定性。
虽然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调用，因此调用服务方法本身并不是实际问题，而是客户端如何知道要发送什么以及如何实际格式化它。 / p>
虽然SOAP客户端通常是针对实现通过WSDL实现的某个合同的存根类编译的，但是可以通过解释WSDL协定并将必要的信息混合在一起来动态调用服务本身，从而发送格式良好的SOAP消息到相应的端点。我在这里看到的问题是，虽然SOAP服务端点以及要调用的方法可以在URI中轻松定义，但是合同描述（WSDL）可能不一定可以通过将?wsdl附加到该URI的结尾因此需要以其他方式指定WSDL协定。
HTML和JSON HAL都没有在链接中定义propper属性，以指示客户端使用某些WSDL协定来生成正确的消息内容。不确定profile是否可以填补这个位置。我目前还不知道任何其他媒体类型或协议。因此，这需要集成到客户端本身的某种隐式（或Fielding将其命名为＃34;带外＆＃34;）信息，如果有人以不同方式发布SOAP服务或其合同，则会增加失败的可能性。客户端将无法再查找该WSDL。
总之，虽然REST应该能够与SOAP合作，但是为了支持客户端动态组装向服务IMO发出有效请求所需的信息，还有一些工作尚未完成。当有这样的支持时，我没有看到通过RESTful客户端发送SOAP消息的主要问题。虽然，我还没有看到任何真实的尝试从（真正的）RESTful API调用SOAP（尽管它们实际上是稀疏的）。通常两者都是分开的。虽然有人试图描述类似于SOAP的REST服务（提示：WADL），但这种方法只不过是RESTful。