Dee*_*ari 5 java rest soap web-services
在阅读了大量有关 Web 服务的文章后，我了解到 REST 可以使用 SOAP 作为协议。但我不明白，在 REST 架构风格中，SOAP 如何以及在哪里适合？
REST 是一种架构风格，如果正确应用，它可以将客户端与服务器解耦，类似于 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 消息发送到服务端。各自的端点。但我在这里看到的问题是，虽然 SOAP 服务端点以及要调用的方法可以在 URI 中轻松定义，但契约描述 (WSDL) 不一定可以通过在?wsdl该 URI 末尾附加 来获得，并且因此 WSDL 契约需要以其他方式指定。
HTML和JSON HAL都没有在链接中定义适当的属性来指示客户端使用某些 WSDL 契约来生成正确的消息内容。不确定profiles 能否真正填补这个空缺。我也不知道目前有任何其他媒体类型或协议可以。因此，这需要将某种隐式（或 Fielding 称之为“带外”）信息集成到客户端本身中，这会增加失败的可能性，以防有人以不同方式发布 SOAP 服务或其合同，因为客户端无法做到这一点。进一步查找该 WSDL。
总之，虽然 REST 一般应该能够与 SOAP 配合，但为了支持客户端动态组装向服务发出有效请求所需的信息（IMO），还需要完成某些工作。当此类支持可用时，我认为通过 RESTful 客户端发送 SOAP 消息不会产生重大问题。不过，我还没有看到任何从（真正的）RESTful API 调用 SOAP 的实际尝试（尽管它们实际上还很少）。通常两者是分开的。尽管有人尝试描述类似于 SOAP 的 REST 服务（提示：WADL），但这种方法完全不是 RESTful。