Bypassing JAX-WS SOAP overhead with JAX-RS/Jersey?

Question

The only web services I've ever integrated with or used have been RESTful. I'm now trying to integrate with a 3rd party SOAP service and am awe-struck at how seemingly convoluted SOAP appears to be.

With REST, I use a JAX-RS client called Jersey that makes hitting RESTful endpoints a piece a' cake. For instance, if a service is exposing a POST endpoint at http://api.example.com/fizz (say, for upserting Fizz objects), then in Jersey I might make a service client that looks like this (pseudo-code):

// 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)
    }
}

But Java-based SOAP clients seem , at first blush, to be fairly more complicated. If I understand the setup correctly, the general process is this:

1. Obtain an XML document called a WSDL from the service provider; this appears to be a language-agnostic description of all the available endpoints
2. Run a JDK tool called wsimport on the WSDL which actually generates Java source code, which implements JAX-WS APIs and actually represents my SOAP client
3. Import those generated source files into my project and use them

First off, if anything I have said about this process is incorrect, please begin by correcting me! Assuming I'm more or less correct, what I don't understand is: why is this necessary if its all an HTTP conversation? Why couldn't I achieve SOAP-based conversations with Jersey, and bypass all this source-generation boilerplate?

For instance, say the same endpoint exists, but is governed by 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)
    }
}

If I understand SOAP correctly, its just a way of utilizing HTTP verbs and request/response entities to send app-specific messages around; it's an HTTP "conversation". So why couldn't I hijack a REST framework like Jersey to HTTP POST messages, and in doing so, bypass this SOAP overhead?

Answer 1

This is going to attract opinion-based answers, but first, you should understand that

• jax-rs is much younger than jax-ws ( jax-ws had a final draft in 2006 , JAX-RS came out in 2008-9 ).

• RESTful webservices standard, for many purposes is quite amorphous - many businesses prefer the comfort of a contract in the form of a WSDL.

• Not to mention that JAX-WS, in concert with WS-I provides many other standards that govern security, message reliability and other enterprise-goodies (under the generic "WS-*" banner) that businesses care about. There's a hodge-podge of libraries that are attempting to get that kind of uniformity on to the jax-rs platform, but for now, jax-ws /WS-I is the industry standard