Kong Konnect 团队最近推出了Portal Management API,它使用户能够通过单个 API 管理其开发者门户。这意味着您可以比以往更轻松地管理门户设置、外观、应用程序注册和注册设置。欢迎联系我们的中国合作伙伴咨询 consultant@gingxing.com。
在本文中,我将向您介绍两个我们认为 Portal Management API 可以帮助简化的场景:
- 自动管理开发者,无需手动批准
- 了解哪些开发者正在(或没有)使用您的 API,并采取措施为受阻的开发者解决问题
自动批准开发者
当每周只有一两位开发者申请时,手动批准他们的应用程序是可以接受的。但是,当您以规模化的方式运行时,这很快就会变得痛苦不堪。这不仅仅是点击“批准”按钮。管理开发者意味着要确保他们及时加入、获得批准并获得适当的权限。
权限方面是关键。开发者只能看到他们有合同权利访问的 API。但是,手动应用权限既耗时又容易出错。让我们围绕新的门户管理 API 开发自动化,以便我们可以批准可信的合作伙伴,并在规模化的情况下将他们分配到各个团队。
要完成此任务,我们将采取以下步骤:
- 获取最近的开发者注册列表
- 根据其电子邮件自动批准任何开发者
- 根据开发者的电子邮件域名分配权限
- 每小时自动运行此脚本
您可以在此处查看我们用于处理新注册开发者的整个脚本。
门户管理 API 提供的 API 返回的数据格式如下:
{
"data": [
{
"created_at": "2023-08-03T23:45:50.042Z",
"updated_at": "2023-08-03T23:45:50.042Z",
"id": "b5f13fcb-190f-4418-a051-79c163770050",
"email": "peter@arsenal.com",
"full_name": "Arsenal",
"status": "pending",
"application_count": 0
},
{
"created_at": "2023-08-22T22:22:12.708Z",
"updated_at": "2023-08-22T22:22:12.708Z",
"id": "6084e049-3a1d-4b62-89a0-970750082016",
"email": "andrea@intermilan.com",
"full_name": "Andrea",
"status": "pending",
"application_count": 1
},
{
"created_at": "2023-10-25T00:04:11.286Z",
"updated_at": "2023-10-25T00:05:15.291Z",
"id": "15075e88-bb30-437a-9d0b-64f1aec8cd0e",
"email": "mike@aol.com",
"full_name": "Mike",
"status": "pending",
"application_count": 0
}
...
],
"meta": {
"page": {
"total": 6,
"size": 100,
"number": 1
}
}
}
我们在 get_newly_registered_developers()函数中调用 GET /portals/{portalId}/developers 端点,它会返回一份待处理的开发者列表。
此时,我们希望自动批准这些开发者。为此,我们调用 process_pending_devs函数:
def process_pending_devs(pending_developers):
for developer_id in pending_developers:
domain = pending_developers[developer_id]
if domain in mapped_teams:
# first approve their signup
approve_developer(developer_id)
# then assign them to the appropriate team (can also do this in a batch, per team)
team_id = email_to_team_mapping[domain][1]
assign_developer_to_team(developer_id, team_id)
此函数将检查开发者(基于其电子邮件地址的域名)是否在我们受信任的合作开发者集合中。如果是,它将批准其注册,并将其分配到与其电子邮件地址相对应的团队。
approve_developer函数通过调用 PATCH /portals/{portalId}/developers/{developerId}:来批准受信任的开发者:
def approve_developer(id):
try:
url = base_url + "/portals/" + portal_id + "/developers/" + id
payload = {"status": "approved"}
response = requests.request("PATCH", url, json=payload, headers=headers)
print(response.text)
except Exception as e:
print("Error approving developer:", id, e)
一旦开发者获得批准,需要分配权限,以便他们可以使用 API。 assign_developer_to_team函数通过调用 POST /portals/{portalId}/teams/{teamId}/developers:来相应地更新开发者的团队映射:
def assign_developer_to_team(dev_id, team_id):
try:
url = base_url + "/portals/" + portal_id + "/teams/" + team_id + "/developers"
payload = {"id": dev_id}
response = requests.request("POST", url, json=payload, headers=headers)
print(response.text)
except Exception as e:
print("Error assigning developer", dev_id, "to team", team_id, e)
在这仅仅95行代码中,我们通过门户管理 API 将原本耗时且易出错的流程自动化了。
现在,我们不再需要手动验证和批准新的开发者注册,而是通过在我们希望的频率上运行 cron 任务来自动批准来自受信任合作伙伴域名的任何开发者注册。
我们不再需要手动将团队分配给这些开发者,而是自动将这些团队(及其关联的产品权限)分配给这些受信任的合作伙伴开发者。
对于一个上午的工作来说,成果还不错吧?
如果您想基于今天所学的内容进行进一步的开发,为什么不尝试以下用例之一呢?
在将开发者分配给团队之前,您可以添加额外的验证。例如,您可以检查每个团队,确保有可供查看/使用的 API 产品。对于尚未有任何活跃开发者的团队,您可能需要检查 a) 是否已为其分配了产品,以及 b) 这些产品的角色是否已正确分配。
如果您有一个“常规”或“公共”团队,而不是拒绝非合作伙伴开发者,您可能希望为他们分配这个非特权团队角色,以便他们可以查看/使用非特权 API。
识别受阻的开发者
在将上述代码投入生产环境一两周后,您发现并非所有合作伙伴都在使用您的API。这可能是由以下两个因素造成的:
- 他们没有正确的访问权限
- 他们因其他原因被阻止
Kong Konnect 提供了创建使用报告所需的基础架构,有助于识别和解锁这些受阻的开发者。接下来,让我们构建以下两份报告:
- 需要分配权限的开发者
- 因其他原因被阻止的开发者
报告1:需要分配权限的开发者
我们需要确保团队权限分配得当,以便我们的开发者能够创建应用程序并注册使用我们的API。我们将使用门户管理API来发现哪些开发者尚未使用任何API。
我们将把以下端点整合到我们的脚本中:
- 使用GET /portals/{portalId}/applications获取所有开发者应用程序
- 使用GET /portals/{portalId}/developers/{developerId}/teams获取开发者被分配到的团队
- 使用GET /portals/{portalId}/teams/{teamId}/assigned-roles获取这些团队的角色
您可以在这里找到我们正在使用的脚本。接下来,我们将逐步介绍相关的函数。
1. 首先,我们在get_all_apps() 函数中使用GET /portals/{portalId}/applications调用获取所有开发者应用程序:
def get_all_apps():
try:
url = base_url + "/portals/" + portal_id + "/applications"
response = requests.get(url, headers=headers)
if response.status_code == 200:
return response.json()["data"]
else:
print("Error:", response.status_code)
return []
except Exception as e:
print(f"Error in get_all_apps: {e}")
return []
2. 接下来,在get_apps_no_reg()函数中,我们仅筛选那些成功注册次数为0的应用程序(意味着它们没有使用我们的任何API)。在报告1中,我们将重点关注那些没有相关消费者权限的开发者。
我们通过两次调用确定每个开发者的消费者权限。首先,我们使用 GET /portals/{portalId}/developers/{developerId}/teams.检索分配给开发者的所有团队。我们得到以下响应:
{
"meta": {
"page": {
"number": 1,
"size": 10,
"total": 1
}
},
"data": [
{
"id": "d3874c1b-2fc7-4d0e-9d58-1ce5307ec1d2",
"name": "Inter Milan",
"description": "Inter Milan Team's API",
"created_at": "2023-11-14T18:06:57Z",
"updated_at": "2023-11-14T23:00:37Z"
}
]
}
接下来,我们使用 GET /portals/{portalId}/teams/{teamId}/assigned-roles检查这些团队的角色。我们得到以下响应:
{
"meta": {
"page": {
"number": 1,
"size": 10,
"total": 1
}
},
"data": [
{
"id": "30f1f1c6-f55f-48c3-90bc-0fb62b07356b",
"role_name": "API Viewer",
"entity_region": "us",
"entity_type_name": "Services",
"entity_id": "1f398e86-4d5d-490c-a447-70340b1481e3"
}
]
}
“API Viewer”权限告诉我们,这个开发者实际上不能消费我们的任何API,因为他们没有“API Consumer”角色。我们将这个开发者添加到我们的“需要Consumer权限的开发者”报告中。我们遍历所有开发者,以查找处于这种情况下的其他开发者。
注意:如果我们想获取更多关于这个服务ID(1f398e86-4d5d-490c-a447-70340b1481e3)的信息,我们可以调用 GET /api-products/{id}.。这将告诉我们关于这个API存在多少个版本、何时创建和更新、发布到了哪些门户,以及API的名称和描述等更多信息。
报告2:因其他原因被阻止的开发者
现在,我们将创建一个报告,其中包含具有正确消费者权限但自创建应用程序以来在过去48小时内仍未注册任何API产品版本的开发者。我们将按照报告1中的相同两个步骤进行操作,但这次在第二步中,我们将重点关注具有正确权限的开发者。
在get_apps_no_reg()函数中的has_permissions 检查会查找具有正确权限但自创建后48小时内未注册以消费任何API产品版本的任何应用程序。我们将这些开发者添加到受阻开发者报告中,并记下要与他们跟进的事项。也许这些开发者无法理解我们的文档。也许他们不理解为什么他们想使用我们的API的使用场景。或者他们可能看足球看得太入迷,放弃了应用程序的开发。无论原因是什么,了解他们是谁会让我们更有信心。
结论
就是这样!通过将这三个端点整合到我们的脚本中,我们现在能够自动向相关的API产品所有者发出警报,提醒他们可能需要跟进的开发者——要么是因为他们需要更多的权限,要么是因为他们可能需要额外的帮助。这样的行动有助于确保我们的开发者能够更快地开始和构建。
请注意,这只是一个非常简化的示例,说明如何管理开发者权限/通知。如果您要在自己的环境中实现,您可能需要考虑以下几点:
- 如果开发者在消费您的API方面没有进展,您应该多久与他们联系一次?
- 不同的开发者团队之间的消费模式是否有所不同?并且应该相应地调整通信吗?
如果您想深入了解代码,可以查看我们使用的整个脚本或阅读文档。欢迎联系我们的中国合作伙伴咨询 consultant@gingxing.com。