Forum Discussion

AAB's avatar
AAB
Regular Contributor
6 years ago
Solved

How to omit parameters in a REST request

Hi,

For my automation project I will have a lot of testsuites and testcases with a lot of combinations. For each testsuite I've entered the necessary parameters to be able to use in each testcase. In ReadyAPI you do that in tab "Projects" on your created webservice.

Now, not all parameters will be filled in for a particular testcase whereas the REST request will send anyways all the parameters as emtpy string.

For this project this is harmful, as an empty string could give an answer, and that isn't what I'm looking for.

For example:

Testsuite parameters: name, cbe_number, country, municipality, neighbours, street, housenumber, po_box

Testcase: Search company on name

For this testcase only parameter 'name' will be filled in, but when I send the request, all other parameters are also filled in in the URL. How can I, per testcase, omit the other parameters please?

Thanks in advance.

  • AAB 

     

    Couple of things:

     

    To be able to use below groovy script, an external library is needed which can be downloaded from here and copied under READYAPI_HOME/bin/ext directory and restart the tool before running it.

     

    Define a custom property at Project level for the service host and post details

    Property name as SERVICE_HOST_PORT and value as http://localhost:8080 (or what ever)

     

    Now coming to each test case, you may want to send certain query and header parameters.

    Define custom properties at test case leve as shown below in the same notation (do not use angular brackets, just shown for separation). Also shown in the picture below.

    QUERY_<parametername> and its value

    HEADER_<parametername> and its value

     

    Define as many query and header parameters as needed for the specific test.

     

    That way, correct parameters can be identified and passed automatically under query, header sections respectively.

     

     

    And now in each test case, you will only have one Groovy Script test step with above content and only custom properties are changed.

     

    You can find the script in text format from my git

    https://github.com/nmrao/soapUIGroovyScripts/blob/master/groovy/rest/VaryingQueryAndHeadersToRestService.groovy

     

     

  • About omitting the parameters...
    If a parameter with an empty value shouldn't be sent, you need to un-check the Required check-box for this parameter in the Advanced options section
     for this parameter.

     

43 Replies

  • richie's avatar
    richie
    Community Hero

    Hi,

     

    I had a similar issue in one of my projects way back, I think you have a couple of choices - go with a groovy script choice to build the request you need dynamically and then publish the request (@nmrao developed a script to enable me to do this)

     

    OR - you can use the OTB functionality - this isn't the best option for a number of reasons.

     

    If you could set the URI's QueryParameters to 'PLAIN' in the SoapUI tab - this would be perfect - but you can't do this unfortunately - if you could do this, this would've saved me a lot of hassle - I've just created a feature request for this exact functionality (link)

     

    Also - you'll see the OTB functionality option is quite awkard because there's a known issue where if you have multiple query parameters in the same 'Resource' level request - you can only have a single request.  

     

    i.e. if you have multiple requests like the following:

     

    /api/{version}/{whatevs}?name=value

    /api/{version}/{whatevs}?cbe_number=value

    /api/{version}/{whatevs}?country=value

    /api/{version}/{whatevs}?municipality=value

    /api/{version}/{whatevs}?neighbours=value

    /api/{version}/{whatevs}?street=value

    /api/{version}/{whatevs}?housenumber=value

    /api/{version}/{whatevs}?po_box=value

     

    you won't be able to use these all in the same REST Service as separate resources because you'll create them fine, then go into the SoapUI tab and try and grab one of the requests, but when it gets created as a 'REST Request' test step, it'll just display the QueryParm of the first one created - even though you can see the individual resources with those different query parms and you selected a different one.

     

    You also have the added complication that I'm guessing you won't just have single query parameters in  your URI's query string - at worst case - you can have the full 8 query parms in your URI's query string.

     

    This is NOT a great answer - but it does get the job done, because it was what I did.

     

    I created a separate Service level item in the Projects level for each different request - so you have 8 single query parms, and then you'll have combinations 8x8 = 64 - so you'll have 64 Service level records (each with a single resource) created in the Projects tab

     

    That's a lot of work! -  by using the OTB functionality this is the only way I've found to do it.

     

    Your other option is groovy - I recently needed to create a request where there are many, many different QueryParms in my request - maybe 500 different values as QueryParameter names.  This, I'm sure isn't the only groovy way of doing this - but it's definitely one way.

     

    nmrao developed the following script - it builds the content of the request (in the format of /api/1/{namespace}/{dataset}?QueryParmName1......................QueryParmName500) from values set in a Properties step

     

    //Script developed by Rao
    //import decs import wslite.rest.* def serviceHost = context.expand ('${#Project#TestEndpoint}') //'https://whatevs.azurewebsites.net' //Below to handle template parameter, additional $ required before def getNamespaceDatasetPath = '''/api/1/${namespace}/${dataset}''' //define all template param values as shown below def binding = [namespace : context.expand( '${#TestCase#namespace}') , dataset : context.expand('${#TestCase#dataset}')] //def binding = [namespace : 'certification-nomenclature', dataset : 'certification-nomenclature'] def template = new groovy.text.SimpleTemplateEngine().createTemplate(getNamespaceDatasetPath) def queryParams = [:] //Get the properties of Property Test step context.testCase.testSteps["Properties"].properties.each { queryParams[it.key] = it.value.value } def client = new RESTClient(serviceHost) def response = client.get(path: template.make(binding) as String, accept: ContentType.JSON, query : queryParams ) assert response.statusCode == 200 log.info groovy.json.JsonOutput.prettyPrint(response.text)

    SO - the above won't allow you to omit certain query parms in your request - but it allows you to build the request's parameters as you need them.

     

     

    Cheers,

     

    richie

     

    • AAB's avatar
      AAB
      Regular Contributor

      Wow richie, thanks a lot for your time and answer!

      And am I happy that someone has been through this also. You understand me completely. And yes indeed, in do time my parameter list will also grow as will the combinations!

       

      Well, I don't know anything about Groovyscripts yet so it's not completely clear what I should change in the script according my project.

      So I guess (bold)

      ('${#Project#TestEndpoint}') //'https://whatevs.azurewebsites.net'

       would mean my projectname + the Endpoint that I'm using

      This (bold)

      def getNamespaceDatasetPath = '''/api/1/${namespace}/${dataset}'''

       I guess in my case the namespace would be "/agents/organizations" en the dataset are the parameters. Yes?

      And for this:

      def binding = [namespace : context.expand( '${#TestCase#namespace}') ,  dataset : context.expand('${#TestCase#dataset}')]

      I guess I should change #TestCase#namespace  and #TestCase#dataset   in to my values. Yes?

      whereas dataset will be 1 or more parameters. Or do I understand it wrongly?

      • nmrao's avatar
        nmrao
        Champion Level 3
        That was solution to richie 's case.

        If you need to use, changes have to be adopted as per your case and modify the changes to the script accordingly.
    • AAB's avatar
      AAB
      Regular Contributor

      Hello avidCoder,

       

      Thanks for the quick reply but this won't work for me. As the parameters are configured in the webservice and that the webservice was assigned to the testsuites and it's childs. So if I change something there, it will manifest itself in all the testcases, won't it?