Forum Discussion

LennSar's avatar
LennSar
Contributor
3 years ago
Solved

Implement several different endpoints in a single environment

Hi there,

 

our API mostly uses one endpoint address which basically is: http://ip/some/path. Now I have a single command in a test case that needs to acces the root address: http://ip/ . 

I set up an environment variable with the first address but when I use it, it blocks the access of the endpoint address for all commands so that I can't change it anymore. How can I achieve the above? The only way I can think of is to change the endpoint address in the open Api spec for ALL requests so that the some/path part of the endoint address is part of each request, which is the last thing we'd like to do.

 

Hope you guys can point me to a different solution!

 

Thanks,

 

Lennart 

Configuration
Function Tests
Test Setup
  • LennSar's avatar
    LennSar
    2 years ago

    Hi KarelHusa,

     

    I just had another idea which I think better suits what I want. I stopped using environment variables and simply replaced in the .xml file every occasion of the endpoint address to be what I have 99% of the time, which is http://IP/some/path. So now I only have to edit the 1% which is under http:/IP/ which is absolutely ok as there are only a handfull of requests that need this. 

    However, thank you very much for taking the time to think about it! Much appreciate it!

     

     

6 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    3 years ago
    Hey LennSar,

    Sorry. Youve lost me again.

    I didnt understand any of "I set up an environment variable with the first address but when I use it, it blocks the access of the endpoint address for all commands so that I can't change it anymore."

    Im quite literal and sometimes that gets in my way of understanding. You use the word "command".....can you also clarify what you mean by this?

    Any screenshots can only help too!

    Cheers,

    Rich
    • LennSar's avatar
      LennSar
      Contributor
      3 years ago

      Hi richie,

       

      no problem, I guess my wording doesn'r really comply with what you could call a 'standard' since I'm quite new to this whole Rest stuff. 

      Here is the example of having no environment variable. The dropdown on the endpoint is still there and I can edit the it to my desire


      Here is an example of using an environment variable. The endpoint now cannot be edited anymore which is a problem since we have a few requests that don't use this endpoint:

       

      So in short what I currently want is to use the environment variable for 99% of the requests in my test suite and for the remaining 1% I want to use a different endpoint address.
      Long story: When importing an OpenApi spec, ReadyApi seems to use the first Server address it can find and applies that to all requests. Unfortunately the first entry in our OpenApi spec is that 1% (which is the endpoint address in the first example screenshot). So instead of manually changing the other 99% of endpoint addresses I wanted to use an environment variable so I would only have to change that 1% again.

      Hope I could clarify what I'm trying to do. If not I'll happily try again 😉 Let me know!

       

      Thanks!

       

      Lennart

      • KarelHusa's avatar
        KarelHusa
        Champion Level 3
        2 years ago

        LennSar ,

        you are right that in Environment configuration a REST API may have just a single endpoint.

         

        Two options come to my mind how to overcome it.

         

        The first is to clone your API definition and give it a different name (see picture bellow). Then you can assigne another endpoint to the cloned API.

         

         

        The second is to use an HTTP request instead of REST request. You can construct your URL using project level properties, so your URL can be also configured per environment.

         

        I like better the first option as ReadyAPI does most of the stuff for us. However, the second is good to resolve tricky situations when the first is not applicable.

         

        Best regards,

        Karel