Mule 4 代理 API：隐藏支持 API 的复杂性，简化客户端交互

介绍

为了向客户端隐藏后端 API 的复杂性，或避免因 API 端点更改而频繁更新客户端配置，本文将提供设计代理 API 的相关思路和建议。

要求

多个 API 部署在不同的主机上供客户端使用，希望通过单个端点处理对不同 API 的多个调用。

代理 API 设计

在 MuleSoft 的代理 API 设计中，客户端只需配置一个单一的代理 API 端点，而无需管理多个后端 API 的配置。在调用时，客户端可以在代理 API 的请求体中传递所需的所有后端 API 信息。代理 API 将代表客户端调用相应的后端 API，并将响应返回给客户端。这些响应可以是有效的，也可能是无效的，代理 API 将确保将其准确传递给客户端。

验证层级设计

第一层验证：CI/CS

根据 MuleSoft 的基本标准，代理 API 将启用默认客户端 ID 强制策略，以确保请求的来源合法。

第二层验证：模式验证

第二层验证涉及有效负载的验证，主要通过 RAML 模式来实现。模式验证将确保以下内容：

• 白名单主机：定义为强制性枚举，确保请求来源于允许的主机。
• 后端端点的方法：REST HTTP 方法被定义为强制性枚举，以确保请求使用正确的方法。
• 端点：后端端点的详细信息。
• Forwarder-content-type：后端 API 期望的内容类型，虽然这不是强制性的，因为某些后端端点可能不需要。
• Body：后端 API 所需的实际负载。该项为可选，依据后端端点的需求。RAML 模式验证中，主体类型被定义为“any”，以适应多种数据格式（如 JSON、字符串、urlEncoded 等）。

RAML 架构示例（在代理 API 中）

将后端 API 主机列入白名单

在此设计中，代理 API 将仅保存主机和端口信息，而不会存储任何客户端或后端 API 的详细信息。这种方式为系统增加了一层安全性，确保后端 API 仅能通过代理 API 访问，而无法通过其他方式直接访问。

标头

基本身份验证、承载令牌、JWT、单点登录（SSO）、客户端 ID、客户端密钥等安全标头都可以通过代理 API 进行传递。这些标头必须在请求的标头部分发送，代理 API 会将其转发至后端。由于这些是敏感数据，设计标准不鼓励将标头值替换为主体/有效负载中的内容。

请求消息示例

HTTP 协议

POST /api/callBackend HTTP/1.1
Host: localhost:8082
Authorization: Basic YW5rdXI6Ymh1eWFu
client_id: test
client_secret: test
Content-Type: application/json
Content-Length: 845

{
    "host": "backend01",
    "method": "POST",
    "endpoint": "/api/createEmployee",
    "forwarder-content-type": "application/json",
    "body": {
        "firstName": "Ankur",
        "middleName": "Jyoti",
        "lastName": "Bhuyan",
        "email": "webmail.ajb@ankuran.online",
        "gender": "Male",
        "phone": 9590951212,
        "currentAddress": {
            "isCurrentAddress": true,
            "street": "Elcetronic City",
            "city": "Bangalore",
            "district": "Bangalore",
            "pin": 56860,
            "country": "India"
        },
        "permanentAddress": {
            "isCurrentAddress": false,
            "street": "3 Rue Renee Aspe",
            "city": "Toulouse",
            "district": "Occitanie",
            "pin": 31000,
            "country": "France"
        }
    }
}

概念证明

为了验证此代理 API 设计，已准备一个概念证明（POC）。该 POC 是通过使用 Mule4 域项目配置开发的，以下是概述。

后端 API

请在此处找到所有 POC 代码，并获取用于测试端点的 Postman 脚本。

作者评论

这种设计特别适合那些频繁更改后端 API 的场景。对于在后端 API 中配置复杂的人来说，这种设计也显得尤为有效。如果希望减少客户端 API 的部署周期，尤其是在后端 API 变化频繁的情况下，这种设计将非常有帮助。此外，这种代理 API 设计可以有效降低开发和部署时间，减轻开发人员的工作量。

需要注意的是，此设计仅在主体类型为 application/json、application/xml、text/plain 或 application/x-www-form-urlencoded 时有效，而不适用于多部分/表单数据（如文件上传）。然而，未来希望能够扩展此设计以支持这一需求。

原文链接：Mule4 Proxy API