在 WSO2 API Manager 中为后端服务和 API 定义定义 URL 模式和版本的推荐方法是什么
在 WSO2 API 管理器中包含 Java 应用程序服务时，我们遇到了问题.我们典型的后端应用程序在 Tomcat 上运行并具有上下文路径，例如(/客户经理).它的 Spring 控制器使用以下格式定义端点:/api/VERSION/resource，例如:/api/v1/customers、/api/v2/customers代码>等
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.
因此，我们对后端的调用如下所示:http://localhost:8080/customer-manager/api/v1/customer.我们自动生成的 swagger 文档将 REST 路径信息发布为 /customer-manager/api/v1/customers.
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.
现在，在 WSO2 中创建 API 定义时，我们被迫指定上下文路径和版本 (/customer-manager, v1) 并且此信息附加到 API 调用中，因此我们的 WSO2 API 调用是这样的:
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.
如您所见，上下文路径和版本重复.
所以这就提出了几个问题:
So this raises a few questions:
我们可以让我们的后端应用程序摆脱它们自己的上下文路径，并将它们部署为 Tomcat (ROOT.war) 中唯一的应用程序.后端应用程序是否没有上下文路径?
为了不复制版本，我们也可以从我们的后端应用程序中删除它，现在有更漂亮的 URL:https://WSO2_HOST:WSO2_PORT/customer-manager/v1/api/customers代码>.但是，在后端应用程序支持 API 的两个同时版本的情况下，我们如何区分哪个后端端点应该处理它们? 请注意，在前面的方法中，我们有两个后端映射 /api/v1/customers 和 /api/v2/customers 并且明确哪个将处理版本化调用.
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.
在后端 URL 中包含上下文和版本详细信息是正常的，并不总是可以从后端中删除它们.通过查看问题，我假设您正在尝试使用 swagger 文件发布 API.也许您必须检查为什么 swagger 定义将/customer-manager/api/v1/customers"设置为 Rest 路径(资源).如果您可以更新后端以将/customer-manager/api/"设置为基本路径并将customer"设置为资源，则可以避免重复的上下文路径.
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.
如果是这种情况，您可以使用以下选项创建 API.
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
如果无法更改 swagger 定义，您可以在 API 管理器中创建 API 定义，方法是如上所述定义资源，而不是使用基于 Swagger 的选项.在这种情况下，您可以使用设计新的 REST API 选项.
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.