更无缝地管理 API 访问

2024-03-06
上海
本文字数：4537 字
阅读完需：约 15 分钟

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获取这些团队的角色

您可以在这里找到我们正在使用的脚本。接下来，我们将逐步介绍相关的函数。

首先，我们在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。

发布于: 刚刚阅读数: 5

Gingxing

关注

还未添加个人签名 2019-03-25 加入

还未添加个人简介

发布

暂无评论

创作场景

更无缝地管理 API 访问

Gingxing

评论