秘密任务 1.0：为什么 DTO 是 API 设计效率和安全性的秘密武器？

在快速发展的软件开发世界中，确保 API 的安全性和效率至关重要。本文探讨了如何通过使用数据传输对象（DTO）来实现这些目标。

想象一下，你正在经营一个超级秘密的间谍机构，需要和你的现场特工进行通信。问题来了？你不能发送太多信息——你可不希望敌方间谍截获敏感数据！

这时，DTO（数据传输对象） 就派上用场了。它是你自己定义的类或对象，用于格式化数据。

把它想象成一个 机密的间谍报告——只发送 必要的 细节，隐瞒任何敏感内容。

什么是 DTO（数据传输对象）？

security-265130_1280.jpg

DTO（数据传输对象）是一种设计模式，用于在进程之间传输数据。

简单来说，它是一个只负责携带数据的对象，不包含任何业务逻辑。你使用它的主要目的是避免直接暴露数据库实体给外部系统或客户端（例如 Web 应用、移动应用）。相反，你定义一个干净、简单且安全的数据版本（仅包含你想暴露的信息）。

把 DTO 想象成间谍的任务报告——你只发送 必要的信息，而忽略所有不必要或敏感的数据。

DTO 的优势：

✅ 保持响应简洁（只传送必要的数据）

✅ 提高安全性（隐藏内部细节）

✅ 提升性能（减少负载大小）

✅ 简化前后端通信

使用 DTO 实现 API

我们创建了一个基本的 间谍机构 API，并使用了 DTO（数据传输对象）来处理请求和响应。接下来我们逐步了解 GET 和 POST 请求的 输入、处理 和 输出。

1. 完整的特工模型（数据库）

我们使用了一个内存数据库（仅为 JavaScript 数组）来存储特工信息，其中包含敏感数据，如 realName、password、missionDetails 和 clearanceLevel。以下是数据库中的一个典型特工：

const agents = [  {    id: 1,    codename: "Shadow Wolf",    realName: "John Doe",    email: "shadowwolf@spyagency.com",    password: "SuperSecret123",    missionDetails: "Undercover operation in Europe",    clearanceLevel: "Top Secret"  }];

问题：

• 当有人请求获取特工详情时，我们希望避免将 敏感数据（如 realName、password 或 missionDetails）返回给客户端。

2. 请求与响应的 DTO

我们创建了两个 DTO：

• agentResponseDTO：用于 格式化响应，只包含 安全的 数据，如 codename 和 clearanceLevel。

• agentRequestDTO：用于 解析传入请求，接受来自请求体的 codename、email 和 password。

响应 DTO（agentResponseDTO）

function agentResponseDTO(agent) {  return {    codename: agent.codename,    clearanceLevel: agent.clearanceLevel  };}

• 用途：将特工对象转换成仅发送 安全 字段的 API 响应。

请求 DTO（agentRequestDTO）

function agentRequestDTO(requestBody) {  return {    codename: requestBody.codename,    email: requestBody.email,    password: requestBody.password  };}

• 用途：将传入的 请求体 转换成只包含 必要字段 的对象。

3. API 端点

GET /agents - 获取安全的特工列表

当你访问 GET /agents 端点时，API 将返回一个 特工列表，但仅包含经过 agentResponseDTO 处理后的 安全数据。这确保了 敏感数据（如密码或任务信息）不会被 暴露。

请求示例：

GET http://localhost:3000/agents

响应示例：

[  {    "codename": "Shadow Wolf",    "clearanceLevel": "Top Secret"  }]

解释：

• 响应只包含每个特工的 codename 和 clearance level，但 不包括密码、真实姓名、电子邮件或任务信息。

• 这样可以保持敏感数据的 隐藏，仅暴露必要的信息给客户端。

POST /agents - 创建新特工

当你向 /agents 发送 POST 请求时，API 将创建一个新特工。请求体 将包含 codename、email 和 password（这些数据会被保存，但不会被返回）。clearance level 将默认设置为 "Classified"。

请求示例：

POST http://localhost:3000/agentsContent-Type: application/json
{  "codename": "Night Hawk",  "email": "nighthawk@spyagency.com",  "password": "superSecret123"}

响应示例：

{  "codename": "Night Hawk",  "email": "nighthawk@spyagency.com",  "clearanceLevel": "Classified"}

解释：

• 请求体 包含客户端提交的数据：codename、email 和 password。

• 服务器处理请求并创建一个新特工，默认将 clearance level 设置为 "Classified"。

• 响应只返回 安全的数据（codename、email、clearanceLevel），不包括密码。

• 密码 会被安全存储（但在实际应用中，密码应该在存储前进行加密）。

其他用户看到的内容

场景 1：获取特工列表（GET /agents）

客户端调用 GET /agents API，并仅接收到 安全信息：

[  {    "codename": "Shadow Wolf",    "clearanceLevel": "Top Secret"  }]

场景 2：创建新特工（POST /agents）

创建新特工时，客户端提交了包含敏感数据（如密码）的请求，但 API 响应时仅返回 安全信息：

请求：

{  "codename": "Night Hawk",  "email": "nighthawk@spyagency.com",  "password": "superSecret123"}

响应：

{  "codename": "Night Hawk",  "email": "nighthawk@spyagency.com",  "clearanceLevel": "Classified"}

即使客户端提交了密码，响应 也不会返回密码。服务器确保只发送 安全的 细节。

在这个例子中，客户端看到的 API 响应是 干净和安全的，并且永远不会暴露像密码或任务详情这样的敏感数据——这要归功于 DTO 的使用。

为什么在 API 设计中使用 DTO？如何构建一个安全的 API？

设计一个既安全又高效的 API 需要一个深思熟虑的结构、数据流和效率的处理方式。

但是借助 APIPost，你可以在不增加不必要复杂性的情况下，高效管理 API 设计。

为什么选择 APIPost 来设计 API？

• 一站式 API 平台 – 设计、测试、调试和文档编写都可以在一个平台上完成。

• 无需登录 – 立即开始工作，无需账户注册。

• 智能认证 – 支持 OAuth 2.0、JWT、AWS 签名等。

• 支持多种协议 – HTTP、GraphQL、WebSocket、SSE、TCP，应有尽有！

• 跨工具兼容 – 可以无缝导入/导出 Postman、Swagger 和 Insomnia。

现在，你的 API 已经 安全、高效、结构化！

通过使用 DTO（数据传输对象），你已经迈出了确保 API 提供 必要数据 同时 保护敏感信息 的重要一步。

使用 DTO 后，你已经有效地组织了 API 设计，提高了 安全性、性能 和 清晰度，让开发者和用户的互动变得更加简单。