How To… Soap UI: REST without WADL

Every month on the third Tuesday as part of our How To…Series, we feature a new post with a guide on how to solve a particular problem with SOAP UI with guest blogger Brendan Connolly. This post looks at using REST without WADL.

Read the other posts in the How To series here.

Browse other posts in the How..To SOAP UI series

How To…Use Dynamic Properties

How To…Testing Client Timeouts And Delays

How To..Manage Basic Requests and Response Logging

How to…complete Parsing With Groovy


Despite the name, SoapUI can be used for testing Restful as well as SOAP based API’s. There are many differences between SOAP and REST but the biggest when it comes to SoapUI is that SOAP apis provide a WSDL. The wsdl defines the contract for the client application, so SoapUI takes that and generates the navigation tree with all possible requests and even populates template xml for them so you can quickly start testing.

The REST equivalent to WSDL is WADL. SoapUI can take a REST services WADL just like it would take a WSDL for SOAP. The difference is not all REST api’s provide a WADL. So what do you do if your api has no WADL, can you still use SoapUI?

One option you may want to consider is having you dev team take a look at adding Swagger in your service. There are other benefits but the most pertinent is SoapUI can automatically generate a WADL from the api documentation Swagger provides.

If you don’t have access to a WADL or Swagger, don’t worry there is still hope. SoapUI supports manually configuring REST services and so you can make use of REST without WADL. Here’s how…

Getting Started

Click the REST icon on the toolbar to start a new REST project. In the New REST Project dialog enter the URI to your service.

Base Url

SoapUI will strip anything after the first slash of the URI you enter in the new project dialog. So next you’ll need to go to the service properties to set the base url for the service. In this example its /v2.

Adding Resources

Here we start adding the various endpoints of the service.
Right click on the URI in the navigation tree and select “New Resource”.

If your resource has a parameter in the the path you indicate that by wrapping the parameter name in curly braces.

The navigation tree should look something like this:

You might have noticed that the naming of the resources is only the last value after the last slash of the path. This isn’t so bad for especially for the first example, but to help with clarity you may want to edit the names.

To do this, select the resource you want to rename in the navigation tree. Then there are a few options different options for this.

Press F2, OR right click and select “Rename” to access the “Rename Resource” dialog.

You can also edit the name in the “Resource Properties” grid on the lower left.

Adding Methods

By default any resource you add will be given a Get method. Depending on the service and resource this may or may not be useful. If you do not need this method you can delete it or repurpose it.

To add a new method, right click your resource and select “New Method”.

From here you can enter a friendly name and select the Http verb from the drop down. You can also add paramters here, but we will cover that later on.

Adding Parameters

Parameters can be added at the Resource, Method, or Request level. SoapUI uses a hierarchical approach to organising parameters. Pratically speaking it means that parameters added at the Resource level will show up across all child requests of that resource. Method level parameters will be available for all child requests.

The process for adding paramters at any level is basically the same. Each level in the navigation tree has a detail view/editor that you can access by double clicking,pressing enter (when node is selected), or right clicking.

For this example we’ll use the Resource level.
To add a parameter click the green plus sign. A new row will appear and allow you to enter a name, value and select the type of parameter.

The icon next to the red X will open a dialog where you can paste in a sample URL so you can let SoapUI extract parameters from it.

Resource vs Request

If you are on a request node adding parameters has one additional option.
The last option in the parameter grid is “Level” this lets you choose if the parameter you are adding to this request should be shared with other methods for this resource.

Requests with Message Bodies

Now that your resources and methods are added you can go to the Request Editor and for the methods that need it enter sample data for the message body.

Creating A Backup

This process may have been a fair amount of work depending on the size of your api. On top of saving your work in a SoapUI project, you have the option to export this data into a WADL. Right Click on the root node in the navigation tree and select “Export WADL”. You never know it may prove useful for other tooling or automation.




About the Author


I am a Software Design Engineer in Test based out of Santa Barbara, California. Working in a variety of testing roles since 2009. I am responsible for creating and executing testing strategies and using his coding powers for developing tooling to help make testers lives easier. He writes tests at all levels from unit and integration tests to API and UI tests. I blog on testing and automation at or follow me on Twitter @theBConnolly
Find out more about @brendanconnolly