问题
We are facing a problem when including our Java application services in WSO2 API Manager. Our typical backend applications runs on Tomcat and has a context path, e.g. (/customer-manager). Its Spring controllers define endpoints with this format: /api/VERSION/resource
, e.g: /api/v1/customers
, /api/v2/customers
, etc.
Thus, our calls to the backend look like this: http://localhost:8080/customer-manager/api/v1/customer
. Our autogenerated swagger documentation publishes the REST path information as /customer-manager/api/v1/customers
.
Now, when creating an API definition in WSO2 we are forced to specify a context path, and a version (/customer-manager, v1) and this information is prepended to the API calls, so our WSO2 API invocations are like this:
https://WSO2_HOST:WSO2_PORT/customer-manager/v1/customer-manager/api/v1/customers
.
As you can see, the context path and the version are duplicated.
So this raises a few questions:
We could make our backend applications get rid of their own context path and deploy them as the only application in Tomcat (ROOT.war). Is it expected that the backend applicacions DON'T have a context path?
In order not to duplicate the version, we could also remove it from our backend app, now having prettier URLs:
https://WSO2_HOST:WSO2_PORT/customer-manager/v1/api/customers
. But, in the case of a backend application supporting two simultaneous versions of an API, how could we distinguish which backend endpoint should process them? Notice with the previous approach we had two backend mappings/api/v1/customers
and/api/v2/customers
and it was explicit which one would process the versioned call.
回答1:
Having context and version details in the backend URL is normal and it is not always possible to remove them from the backend. By looking at the question I assume you are trying to publish an API using a swagger file. Maybe you have to check why the swagger definition sets "/customer-manager/api/v1/customers" as the Rest path(resource). If you can update the backend to set the "/customer-manager/api/" as the base path and "customer" as the resource the repeating context paths can be avoided.
If that is the case you can create the API with the following options.
Name: customer-manager
Context: /customer-manager/api
Version: v1
Resource: customers (This will be identified through Swagger definition)
Backend URL: http://localhost:8080/customer-manager/api/v1
If changing swagger definition is not possible, you can just create the API definition in API Manager by defining the resource as I mentioned above instead of using the Swagger based option. You can use the Design a new REST API option in this case.
来源:https://stackoverflow.com/questions/53720241/whats-the-recommended-way-to-define-url-patterns-and-versioning-for-backend-ser