Forum Discussion

Chas_Schley's avatar
Chas_Schley
Occasional Contributor
16 years ago

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_

1 Reply

Sort By
  • omatzura's avatar
    omatzura
    Super Contributor
    16 years ago
    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