Forum Discussion

CKTester's avatar
New Contributor
3 years ago

Resource Path contains spaces

Hi Guys,   I have REST API GET resquest where the Resource path contains a space. When running the request ReadyAPI does not encode the space in the Resource path to %20. Spaces in Parameters are e...
  • TNeuschwanger's avatar
    3 years ago

    Hello CKTester 


    Thank you for all the detail of your issue.  What is the question?   😉


    If Smartbear did that purposefully, it looks like you will need some work around to be able to have spaces in the value.  If you think it is a bug, you can report the issue to the ReadyAPI Support team  - you can do this here:


    What you presented looks like a local endpoint so I would guess it is a method still under development.  If it is not a production method yet, is it possible to communicate with the developer that it would be helpful to NOT have a space in the method call?  I don't know how common it is to use space in a method name.  The methods names I have encountered do not contain space.


    If the method name must contain a space and Smartbear did what you are encountering purposefully, then an alternative could be to fix the resource name in a groovy test step to write the corrected value to a property and reference that property in the requested resource.



    /lookups/${#Project#fixedComCatStr}     // if you put the property at project level


    /lookups/${Properties#fixedComCatStr}       // if you put the property in a properties test step at test case level


    Putting the name into a property also helps if the name is still undecided and will be changing often.  Keeping it as a property allows it to be kept in one location where multiple test cases can access it.  When there are multiple test cases accessing it, it can be changed in one location and you won't have to crack open all the test cases where it is used when modification is needed.




  • richie's avatar
    3 years ago
    Hey CKTester,

    I think this is a defect.

    URI encoding is standard http and is described in the http RFCs quite clearly and i dont see a reason to code the function to not support uri/% encoding the resource when it encodes the rest of the uri. I know you can workaround by manually inserting the space encode, but you shouldnt have to and the uri/% encoding checkbox available on the api description should force this automatically (its set as default, or it used to be as im guessing Smartbear are aware of the Uri/% encoding http RFC).

    Smartbear might be aware of this already, but they might not be, so as Todd suggested, it's still a good idea to raise a ticket witj Smartbear about this.