java - Bypassing JAX-WS SOAP overhead with JAX-RS/Jersey? -
the web services i've ever integrated or used have been restful. i'm trying integrate 3rd party soap service , awe-struck @ how seemingly convoluted soap appears be.
with rest, use jax-rs client called jersey makes hitting restful endpoints piece a' cake. instance, if service exposing post endpoint @ http://api.example.com/fizz (say, upserting fizz objects), in jersey might make service client looks (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, @ first blush, more complicated. if understand setup correctly, general process this:
- obtain xml document called
wsdlservice provider; appears language-agnostic description of available endpoints - run jdk tool called
wsimportonwsdlgenerates java source code, implements jax-ws apis , represents soap client - import generated source files project , use them
first off, if have said process incorrect, please begin correcting me! assuming i'm more or less correct, don't understand is: why necessary if http conversation? why couldn't achieve soap-based conversations jersey, , bypass source-generation boilerplate?
for instance, same endpoint exists, governed soap:
class fizzclient { webresource webresource = initat("https://api.example.com") fizzserializer serializer // take fizz instances , turn them xml fizzdeserializer deserializer // take xml , turn them fizz instances upsertfizz(fizz fizz) { string xmlfizz = serializer.serialize(fizz) webresource.path("fizz").post(xmlfizz) } } if understand soap correctly, way of utilizing http verbs , request/response entities send app-specific messages around; it's http "conversation". why couldn't hijack rest framework jersey http post messages, , in doing so, bypass soap overhead?
this going attract opinion-based answers, first, should understand
jax-rs younger jax-ws (jax-ws had final draft in 2006, jax-rs came out in 2008-9).
restful webservices standard, many purposes quite amorphous - many businesses prefer comfort of contract in form of wsdl.
not mention jax-ws, in concert ws-i provides many other standards govern security, message reliability , other enterprise-goodies (under generic "ws-*" banner) businesses care about. there's hodge-podge of libraries attempting kind of uniformity on jax-rs platform, now, jax-ws/ws-i industry standard
Comments
Post a Comment