cancel
Showing results for 
Search instead for 
Did you mean: 

Substituting query parameter values into a REST resouce path

Highlighted
Occasional Contributor

Substituting query parameter values into a REST resouce path

We have a REST service that places variable parameters as part of the request URI (instead of passing them in as query parameters).  The general form of the URI is:

/metadata/device/{deviceId}/image/{imageId}

For example, a GET of /metadata/device/123456/image/987654 would return metadata related to device 123456 and image 987654.

My test step is the keeper of the particular device and image IDs, and I need to pass those values in to the URI that gets called as part of the REST service.

When I hard-code specific device and image IDs into the Resource Path on the resource and then invoke a test step, then I get a valid response.  I have tried these substitutions:
/metadata/device/{deviceId}/image/{imageId}
/metadata/device/${deviceId}/image/${imageId}
/metadata/device/{#deviceId}/image/{#imageId}
/metadata/device/${#deviceId}/image/${#imageId}
/metadata/device/${#TestSuite#deviceId}/image/${#TestSuite#imageId}

and each of them spit up:

ERROR:java.lang.Exception: org.apache.commons.httpclient.URIException: escaped absolute path not valid

in the error log.

What's the trick for pushing teststep-level properties into a REST resource path?

Thanks!

_chas_
Thanks,

-Chas
1 REPLY 1
Highlighted
Super Contributor

Re: Substituting query parameter values into a REST resouce path

Hi chas!

there are two ways:

1) the "REST way":
- define corresponding parameters in the parameters table and set their type to "TEMPLATE"
- in the path create placeholders using {} syntax, ie /metadata/device/{deviceId}/image/{imageId}
- set the values of the parameters either statically or with standard soapUI property-expansion, ie ${#TestCase#someTestCaseProperty}

2) the "soapUI way":
- upgrade to 2.5.1
- use property-expansions in the path like in your last example, ie /metadata/device/${#TestSuite#deviceId}/image/${#TestSuite#imageId}
-> These were not properly replaced in 2.5, 2.5.1 should fix the error message..

The primary reason to choose nr 1 over nr 2 is that the generated WADL will contain correct parameter definitions (if you open the interface window and look at the "WADL Content" tab)

regards!

/Ole
eviware.com
New Here?
Join us and watch the welcome video:
Announcements
Top Kudoed Authors