how to generate Postman collection with various basePath s (e.g. /v1 and /v2)

[armen-ch]

hello,
I have an OpenAPI spec with paths having v1 basePath excluding 2 of them. POST actions of those have v2 as basePath.
How can I setup Portman configuration to generate Postman collection which will have the appropriate request urls with v2 basePath for the aforementioned 2 POST actions (like http://somehost/v2/endpoint) and with v1 for the rest (like http://somehost/v1/endpoint)?
I know this is not a good practice to use different basePaths for the same service and moreover OAS 3 utilizes servers url instead of the "host", "basePath" and "schemes" keywords used in OpenAPI 2.0 but this is what I have.

[thim81]

hi @armen-ch ,

In my experience, for such a use-case tend to include the version in the operation path.
This will allow you to define a schema, description, ... everything you want to document + it allows you to showcase all information for v2 of the operation.

Example: http://somehost/v2/endpoint

BasePath: http://somehost

/v1/endpoint:
  get:
    description: Version 1 of the endpoint, returns all
    responses: 
/v2/endpoint:
  get:
    description: Version 2 of the endpoint, returns all
    responses: 

[armen-ch]

Thanks @thim81, I was actually thinking about such a solution, but since I'm not the owner of the specs, I wanted to see if Portman can provide more neat solution.

[thim81]

Portman follows the OpenApi spec and the baseUrl is used during the conversion to Postman.
I can't see any clean solution to overcome this from within Portman.

As a workaround, you could script a pre-processing script where you could work with a custom OpenApi extension tag and use that to convert the original OpenApi doc into a manipulated OpenApi document where the base URL is replaced or moved to a place where it makes sense.

[armen-ch]

I think a possible and preferable solution would be the approach I described in #408, and I think this is in line with the Open API standards. Another solution could be something like overwriteRequestBasePath or overwriteRequestBaseUrl. And better to have both of them :) This would bring more flexibility without breaking any standards. Is this something difficult to implement?

[armen-ch]

Hi @thim81, can you please take a look at "Relative URLs" section of API Server and Base URL OAS document.
It states that if relative path is specified on the path level or operation level and if the definition hosted for instance at http://localhost:3001/openapi.yaml and specifies url: /v2, the url is resolved to http://localhost:3001/v2. So based on that specification Portman can generate sever url as baseUrl + relative url (e.g. /v2). Also see #408 . This is exactly what is needed. And I think, it would be good addition to Portman functionality.

[thim81]

@savage-alex, curious how you would handle this case of versioning as part of the base URL?