Forum Discussion

multiware's avatar
multiware
Occasional Contributor
10 years ago

REST, MockAction, using template parameters in ResourcePath

Hi,

I'm working on the REST service mock and need a way to process URIs with template parameters,
something like this:

http://localhost:8080/edit/{id}

I need to be able to:
- process /edit/1 .... /edit/999 with the same MockAction, does MockAction support any kind of "parameterized" request paths?
- extract {id} parameter from the uri in order to use this parameter in scripts.

is this possible with SoapUI?

6 Replies

  • nmrao's avatar
    nmrao
    Champion Level 3
    I believe that this is possible. Have you tried?
  • I have similar requirements, and also can't get it working. The regular Service Resources have parameters, but Mock Service Resources do not. For regular Service Resource parameters, it is also possible to directly substitute project properties into the resource path ( like /edit/${#Project#foobar} ), but this is doesn't work for Mock Service Resource Paths.

    Anyone have some other method of generating dynamic Resource Paths for Mock Service resources?
  • Hi Guys,

     

    I have the same issue, I need to test my webservice against a REST Mock/Virt since the server is not yet implemented. The resource path should however be parameterized so I don't have to implement a unique VirtAction for every possible REST request I might like to test.

     

    I tried using property expansion inside the Resource Path without success, e.g.: /abcd/${#MockService#abcid}/Heartbeat instead of /abcd/012345/Heartbeat

     

    I'm using Ready!API 1.4

     

    Has anyone found a solution to this? I would really appreciate any insights you guys might have as I'm pretty new to SoapUI

     

    Thx!

  • Sounds like you actually have to script a mock request at the highest level of the REST resource hierarchy :-(

     

    https://stackoverflow.com/a/37343814/796761

     

    Which is a major pain. Because our API's REST resources are subpaths of each other, and you can't use template parameters or wildcards in mock patterns. So I'd have to script the entire base path or create all kinds of duplicates with hardcoded values, in order to distinguish, say,

     

    /calendar-backend/public/api/v1/services

     

    from

     

    /calendar-backend/public/api/v1/services/1/branches

     

    from

     

    /calendar-backend/public/api/v1/services/2/branches