Web services are great aren’t they? You can easily link Java code, .NET code, and even many more obscure languages together with some type of XML-based web service. However, working with all of these different sources of code can be a little concerning as bug tracking and testing is concerned. Often times, when a change occurs it could impact several areas, which is why it’s great to have a tool to test just the web service (or a collection of web services) and experiment with different values passed to the service quickly.
I’m sure there are several options out there but I’ll share the open source one I’ve been using lately, SoapUI. Here are a few steps to get you started:
Step 1 – Download and Install
Head over to SourceForge and download SoapUI community edition. (I think I recently read that SourceForge owns ThinkGeek – if you haven’t been to ThinkGeek you’re not a true geek!)
Step 2 – Create a New SoapUI Project
Enter the project name to whatever you like (CalculatorWebservice, for example).
Enter the WSDL location of the web service; this can either be local or a remote address. If you would like to follow along you can use the following public web service URL: http://soatest.parasoft.com/calculator.wsdl.
By default “Create sample requests for all operations” should be checked, this creates a stub request which you can modify to plug in your own values later on.
Step 3 – Open Stubbed Request
Use the navigation tree on the left side of the window to open your new project you’ve created, this should read “CalculatorWebservice”. Choose an operation to expand (we’ll use “Add”) until you expose “Request 1”. This is the stubbed request that you will alter to begin testing the web service. Double click “Request 1” to open the XML request in a new window.
Step 4 – Modify and Send Request
The nodes will originally display a “?”, expecting you to enter a value for the nodes. Enter all values that you would like to pass into the web service. If you are following along with the example, you can enter 1 for x and 4 for y. Click the green run button in the top left to send the web service request.
Step 5 – Evaluate Response
The split screen will now favor the response window which should have the XML response returned from the web service (if you passed in bad data or if the web service failed, you should see the failure related response as well).
You now have a quick and easy way to load up multiple web services, adjust the input values and test the responses before complicating the situation with your own code. Hope this helps!
So is this something that in the past you could test with something like curl?
I’m not very familiar with cURL, but I believe this is a bit different. SoapUI can be setup as projects as opposed to command line, and it dives deeper into web services.