Now we really need to have a more detailed look at the different types of REST Parameters available to you in soapUI. There are five types of parameters available; QUERY, HEADER, TEMPLATE, MATRIX and PLAIN:

Let’s have a look at these in more detail (except the PLAIN type which is ignored) to see how they can be used for parameterizing your resources.

1. QUERY Parameters

QUERY parameters are the most common type of parameter that is appended to the path of the URL when submitting a request. You can see them added to the path after a ‘?’ in the path preview at the top of the REST Request editor:

If you are simulating HTML Form submits, you might want to them to use the POST method instead. If we create a corresponding REST Method using the POST (or PUT) verb you will get an option to post query-parameters in the body instead:

As you can see selecting the option removes the parameter from the path, and if you submit and look in the Raw tab you will get:

As you can see the parameters have been added to the body of the message instead, with the corresponding Content-Length set accordingly.

2. HEADER parameters

HEADER parameters are instead added as HTTP Headers to the outgoing request. Let’s define one at the Method level:

Now going back to the request editor we see:

Setting a value and submitting the request gives the following in the Raw request tab:

3. TEMPLATE Parameters

TEMPLATE parameters are a flexible way of parameterizing the actual path of the request.  This comes in handy with twitter since it defines the response format as the extension of the search path (“.json” or “.atom”). Let’s define a parameter so we can easily change the format, now at the Resource level:

Ok, there are quite a lot of things being done here:

• We’ve opened the Search Resource window
• We’ve added a parameter named “format”, set its type to “TEMPLATE” and set the default value to “json”
• We’ve changed the path of the resource to “/search.{format}”, which is the notation used to specify where in the path the “format” parameter should be inserted.
• We’ve added some metadata on the parameter at the bottom.

Now if we go back to the request editor and change the value to “atom” instead:

We can see the Full Path getting the “atom” extension instead and submitting the request gives an XML Response instead of the previous JSON response. If we haven’t done this before, a corresponding Response Representation automatically gets added to the Method (and underlying WADL) as can be seen in the Representations inspector for the response:

Finally, if we instead use the From view of the request (in soapUI Pro only), we can now see what the extra metadata added for the parameter is used for (besides for creating nicer WADLs):

Here the format is rendered as a drop-down with the “atom” and “json” options available.

4. MATRIX Parameters

MATRIX parameters are another way of defining parameters to be added to the actual path of the resource, but before the query string. They are not as common but never the less specified in the WADL spec and thus supported by soapUI. Add a MATRIX parameter to the search method (as we did for the HEADER parameter above):

Back in the request editor we now get:

As you can see, the parameter is added to the path before the query string. Submitting the request now gives a 406 error from Twitter:

This is trustily added to the response representations for the method as a Fault Representation: