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:

Obtain an XML document called a WSDL from the service provider; this appears to be a language-agnostic description of all the available endpoints
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
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?

this may help stackoverflow.com/questions/19884295/soap-vs-rest-differences — Uttesh Kumar
Thanks @UtteshKumar (+1) - however I understand, in principle, the differences between SOAP and REST. I guess I'm just pointing out that Jersey can be used to send any type of entity, as any type of content, to any URL, using any HTTP verb...so why (ever?) use JAX-WS/SOAP if it can be mimicked with REST/Jersey? — smeeb

kolossus kolossus · Accepted Answer · 2015-04-28T19:32:46

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

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

1 Answers