通过JAX-RS / Jersey绕过JAX-WS SOAP开销？

Question

我曾经与之集成或使用过的唯一Web服务是RESTful。 我现在正在尝试与第三方SOAP服务集成，并对SOAP看起来似乎有些费解感到震惊。

在REST中，我使用了一个称为Jersey的JAX-RS客户端，该客户端使RESTful端点的实现成为一个难题。 例如，如果某项服务在http://api.example.com/fizz公开了一个POST端点（例如，用于提升Fizz对象），那么在泽西岛，我可能会制作一个如下所示的服务客户端（伪代码） ：

// Groovy pseudo-code
class Fizz {
    int type
    boolean derps
    String uid
}

class FizzClient {
    WebResource webResource = initAt("https://api.example.com")

    upsertFizz(Fizz fizz) {
        webResource.path("fizz").post(fizz)
    }
}

但是基于Java的SOAP客户端乍一看似乎要复杂得多。 如果我正确理解安装程序，则一般过程如下：

1. 从服务提供者那里获取一个称为WSDL的XML文档； 这似乎是所有可用端点的语言不可知的描述
2. 在WSDL上运行一个名为wsimport的JDK工具，该工具实际上会生成Java源代码，该代码实现JAX-WS API，并且实际上代表了我的SOAP客户端
3. 将那些生成的源文件导入到我的项目中并使用它们

首先，如果我对这个过程所说的话不正确，请先纠正我！ 假设我或多或少是正确的，我不明白的是： 如果这全部是HTTP对话，为什么需要这样做？ 为什么我不能与Jersey进行基于SOAP的对话，而绕开所​​有这些源代码生成样板？

例如，假设存在相同的端点，但是由SOAP来控制：

class FizzClient {
    WebResource webResource = initAt("https://api.example.com")
    FizzSerializer serializer // I take Fizz instances and turn them into XML
    FizzDeserializer deserializer // I take XML and turn them into Fizz instances

    upsertFizz(Fizz fizz) {
        String xmlFizz = serializer.serialize(fizz)
        webResource.path("fizz").post(xmlFizz)
    }
}

如果我正确理解SOAP，那只是利用HTTP动词和请求/响应实体来发送特定于应用程序的消息的一种方式。 这是一个HTTP“对话”。 那么，为什么我不能将诸如Jersey的REST框架劫持到HTTP POST消息中，而绕过此SOAP开销呢？

Answer 1

这将吸引基于意见的答案，但是首先，您应该了解

• jax-rs比jax-ws小得多（ jax-ws 于2006年发布了最终草案 ，JAX-RS于2008-9年问世）。

• 出于许多目的，RESTful Web服务标准是完全不稳定的-许多企业更喜欢以WSDL形式签订合同。

• 更不用说JAX-WS与WS-I一起提供了许多其他标准，这些标准管理企业关心的安全性，消息可靠性和其他企业用品（在通用的“ WS- *”旗帜下）。 有各种各样的库正在尝试将这种统一性引入jax-rs平台，但是就目前而言， jax-ws / WS-I是行业标准