Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URI Pattern Inside and Outside of API ML #66

Closed
dkelosky opened this issue Oct 24, 2019 · 4 comments
Closed

URI Pattern Inside and Outside of API ML #66

dkelosky opened this issue Oct 24, 2019 · 4 comments

Comments

@dkelosky
Copy link
Contributor

If we follow this:

   routes:
        - gatewayUrl: api/v1
          serviceUrl: /api/v1

We may have an endpoint outside of the API ML that is: /api/v1/status.

Then, through the API ML, we would then have /api/v1/servicename/status

A concern is that this might make it difficult to be a client for both cases. Is that valid or is this normal in an API ML?

@plavjanik
Copy link
Contributor

What would you suggest?

To have /serviceid/api/v1/status at the API Gateway?

That would make more sense to me now. If we want to change it, we have to discuss it with the API squad and do it before LTS.

@dkelosky
Copy link
Contributor Author

It's a pretty disruptive change, but I think it would be less confusing to teams. I can ask them to comment here, would that be helpful?

@plavjanik
Copy link
Contributor

plavjanik commented Oct 26, 2019

I think that the issue should be opened in zowe/api-layer. SDK just follows it. If API squad agrees that it is feasible to change it and what options makes sense then we should ask. There can be many implications of changing the format so we should present only the options that we can implement with reasonable effort.

@dkelosky
Copy link
Contributor Author

dkelosky commented Oct 28, 2019

Good point - I copied the issue there and will close this one. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants