Need to hit a SOAP service from the command line? The curl tool may be just what you need.
If your job entails a degree of web service support you’ll doubtless find yourself needing to fire ad hoc requests into those services from time to time. If your job entails a degree of web service support you’ll doubtless have found the rather nifty SoapUI tool to help you do it.
There aren’t many situations where SoapUI wouldn’t have your back. As a Java application you can plant it on any box that has Java installed and it’s also nicely scriptable so you can embed it in a headless fashion in shell scripts or Maven builds.
Nice.
Unfortunately, however versatile and powerful SoapUI may be, there are an army of system administrators and corporate procedure wonks just waiting to totally knacker it for you. Can I install this support tool on your prod server? Can I install Java on your non-Java prod server? Can I access your prod server from my desktop? The man from ops, he says no (after he’s recovered from fainting).
Without wishing to give the thought police a pass, if all you need to do is ping a request at a service and check the response, or have a shell script heartbeat it every few minutes, SoapUI might be something of a sledgehammer to crack a nut. For these cases, the humble curl command might be all you need.
For the uninitiated, curl is an open source command (and embeddable library) for making requests over common Internet file transfer protocols – most notably HTTP. There are pre-canned builds for most common operating systems and many Linux distros feature it, so you may find it already installed or only a politically acceptable yum command away.
In Java Quick Start – JAX-WS code-first web services with CXF and Spring we created a simple country code lookup web service. Here we’re going to hit it from the shell using the curl command.
First of all we need to create an XML document containing our SOAP request. Few of us are “gifted” enough to knock one of these out by hand, but since it’s exactly the same request SoapUI would generate, we can use it to create one and copy the text into our request.xml document:-
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:coun="https://www.devguerrilla.com/countryLookupService">
<soapenv:Header/>
<soapenv:Body>
<coun:getCountryName>
<countryCode>GB</countryCode>
</coun:getCountryName>
</soapenv:Body>
</soapenv:Envelope>
Firing this at our web service with curl couldn’t be easier:-
curl -d @request.xml http://localhost/countryLookupService > response.xml
All we’re doing here is using the -d option to specify the HTTP POST data we want to send with @request.xml to tell it to read the data from our file, then finally redirect the output to response.xml to capture it.
<soap:Envelope>
<soap:Body>
<ns2:getCountryNameResponse>
<countryName>Great Britain</countryName>
</ns2:getCountryNameResponse>
</soap:Body>
</soap:Envelope>
There are limitations to this approach – if you web-service uses any clever third-party security mechanisms for example you might be screwed – but curl does give you plenty of options to finesse how your request gets submitted. For example, if you’re looking at issues that might result from character set conversion you can force the HTTP Content-Type for your request with the -H option to add the necessary request header:-
curl -H "Content-Type: text/xml;charset=UTF-8"
-d @request.xml http://localhost/countryLookupService > response.xml
As any good guerrilla knows, when you can’t use your AK-47 a sharp knife will often suffice. Tools like curl offer a great way of hitting web services when tools like SoapUI aren’t an option.
