在WSO2 API管理器中为后端服务和API定义定义URL模式和版本控制的推荐方法是什么?
在将我们的Java应用程序服务包含在WSO2 API Manager中时,我们面临一个问题.我们典型的后端应用程序在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.也许您必须检查一下为什么招摇的定义将"/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 Manager中创建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.