Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

Use the backendBasePath to adjust the Host inside the Swagger-File #81

Closed
vuvdoan opened this issue Jun 11, 2019 · 5 comments
Closed

Use the backendBasePath to adjust the Host inside the Swagger-File #81

vuvdoan opened this issue Jun 11, 2019 · 5 comments
Assignees
Labels
done The issue is merged into the development branch and with that part of the next release. enhancement New feature or request next release Planned for the next release

Comments

@vuvdoan
Copy link

vuvdoan commented Jun 11, 2019

Hi,

I've defined the backendBasePath in the config/contract file and publish my API with the tool. After publishing a frontend API and a backend API were created in the axway API manager. So far so good.

Unfortunately the backendBasePath is only substituted for the frontend API (backend service url) but not for the backend (base path url). Resulting the certificated cannot be downloaded automatically.

It seems like this parameter backendBasePath does not have the same effect as having host parameter in the swagger file at all. If a host param is defined in the swagger file and I publish it with the tool. Everything works fine.

Is this work as designed? I don't want the host param to be defined in the swagger file, since I have multiple stages. Can you please check?

Thanks,
Vu

@cwiechmann
Copy link

Yes, that's expected behavior as the parameter: backendBasePath controls the API-Manager Proxy-Configuration and is not changing the Swagger-File itself.
And as the backendBasePath is configured on the FE-API, it has no impact on the Backend-URL.

Does it makes sense?

@vuvdoan
Copy link
Author

vuvdoan commented Jun 12, 2019

that's the answer I was afraid of :) Thanks for clarification.
Is there a way to parameterize (actually replace the host param in the swagger file) with this tool?

@cwiechmann
Copy link

Not at the moment. Perhaps something which can be added later. Should be an easy thing to do, as the Swagger-File is loaded internally anyway.

@cwiechmann cwiechmann self-assigned this Jun 13, 2019
@cwiechmann cwiechmann added the enhancement New feature or request label Jun 13, 2019
@cwiechmann cwiechmann changed the title backendBasePath does not overwrite host and port in swagger file properly Optionally use the backendBasePath to adjust the Host inside the Swagger-File Jun 13, 2019
cwiechmann pushed a commit that referenced this issue Jun 20, 2019
backendBasePath to replace or set the host parameter in the
Swagger-Definition. 
This can be turned off using the parameter: replaceHostInSwagger
@cwiechmann cwiechmann changed the title Optionally use the backendBasePath to adjust the Host inside the Swagger-File Use the backendBasePath to adjust the Host inside the Swagger-File Jun 20, 2019
@cwiechmann
Copy link

@vuvdoan, As the enhancement makes so much sense, I decided to implement this feature for the next release, which is now done.
I have even decided to perform this by default (only for JSON Based Swagger-Files). For anybody who don't want this, it can be turned off using the "hidden" parameter: "replaceHostInSwagger" set to false.

See env.properties.sample for reference in the next release. Can also be used as a normal CLI parameter.

However, the code is implemented in way, if the replace fails for any reason, it is logged with an error message + exception trace, but the tool continues.
Also please note, as the backendBasePath is now changing the Swagger-File (APIDefinition) the tool will consider it as a changed property. And as a changed API-Definition leads to a Re-Creation of the API, from now on changing the backendBasePath, will re-create the API. In the same way, as it happens when doing any other change in the Swagger-File. Hope this okay?

@cwiechmann cwiechmann added done The issue is merged into the development branch and with that part of the next release. next release Planned for the next release labels Jun 20, 2019
@cwiechmann
Copy link

Released with version 1.5.3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
done The issue is merged into the development branch and with that part of the next release. enhancement New feature or request next release Planned for the next release
Projects
None yet
Development

No branches or pull requests

2 participants