添加减速和错误代码--用 C# 构建示例 API 课程

Tim Corey

16m 21s

在构建和测试现代应用程序（尤其是具有网络前端的应用程序）时，开发人员经常需要模拟实际场景，如 API 延迟和意外错误响应。 为了支持这一点，Tim Corey 在题为"Adding Slowdowns and Error Codes - Building a Sample API in C#"的课程中介绍了一个实用性很强的演练。 在这段视频中，Tim 演示了如何用人工延迟和自定义错误响应来丰富一个最小的 C# API，这些都是在测试过程中模拟不理想情况的宝贵工具。

在本文中，我们将向您介绍 Tim 在视频中演示的概念和实现方法。

示例 API 介绍及其目的

Tim 在课程开始时重申了在学习网络开发时拥有示例 API 的价值。 这样的应用程序接口为您提供了测试前端应用程序的具体依据。

课程结束时，Tim 的目标是建立一个强大的 API，其中包括

• 样本数据

• 文档

• 健康检查

• 模拟减速

• 模拟错误

• 通过 Docker 和 VPS 的部署选项

在这一具体课程中，Tim 将重点放在模拟速度变慢和生成错误代码上，以便在不利条件下实现逼真的 API 行为。

为 API 端点添加人工延迟

蒂姆首先为特定的 API 端点（尤其是处理课程数据的 API 端点）添加了一个可选的延迟参数。 他的目标是模拟缓慢的 API 响应，以便更好地进行前端测试。

实施细节：

• 延迟参数是一个代表毫秒的可空整数。

• 为此，Tim 将端点方法转换为异步方法 (async)，返回 Task<IResult> 而不仅仅是 IResult。

• 如果提供了延迟且在可接受的范围内（不超过 300,000 毫秒或 5 分钟），该方法会调用 Task.Delay() 暂停执行。

在 2:33 分，Tim 强调了限制延迟的重要性。 他设定了 5 分钟的上限，以防止不合理的等待时间导致应用程序反应迟钝或出现故障。

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

该新增功能可确保开发人员模拟长达五分钟的延迟，这对测试客户端应用程序的超时和响应速度非常有用。

测试延迟机制

Tim 使用 Postman（或 Postman 克隆）进行了一些测试，以验证延迟逻辑。 例如：

• 延迟=5000（5 秒）会导致 API 在返回结果前暂停。

• 延迟=500 会导致停顿时间缩短。

他注意到，由于处理开销，实际延迟总是比指定值稍长，这是现实世界中一个重要的细微差别。 正如 Tim 在5:09所指出的，您并不是在对 API 进行精确到毫秒的计时，而是在模拟一个阈值。

将延迟功能扩展到更多端点

Tim 并不满足于 "加载所有课程 "的终端。 他希望保持一致性，因此在 "按 ID 加载课程 "端点中实现了相同的延迟功能。

在 6:15 分，他遇到了一个障碍：在转换为异步时，由于方法名称中自动添加了 "Async"，导致命名冲突。 Tim 调整了这两个方法的名称，使其与 Async 命名约定保持一致，以确保清晰度和一致性。

测试确认实施：

• 尊重延迟。

• 不存在的记录在延迟后会如期返回 404。

• 移除延迟或传递空值的行为是正确的，Tim 指出这是 Postman 的 UI 怪癖，而不是 API 本身的问题（8:00）。

添加自定义错误响应

接下来，Tim 介绍了 API 测试的一个重要工具：一个可以模拟各种 HTTP 错误代码的专用端点。

在 9:13 分，他解释说，虽然某些端点（如按 ID 返回课程的端点）会因数据丢失而自然返回 404，但除非明确模拟，否则没有内置方法来测试其他错误代码。

蒂姆在 /error/{code} 上创建了一个新的端点，该端点：

• 接受整数 HTTP 状态代码。

• 使用开关表达式返回相应的 HTTP 错误响应。

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

这既包括常见的客户端错误，也包括开发人员可能希望测试的任何自定义代码。

12:03时，他通过 app.AddErrorEndpoints() 将新端点添加到程序中，并将错误类标记为静态。

测试错误端点

Tim 现在通过传递各种状态代码来测试错误端点：

• 400 返回 "错误请求

• 401 返回 "未授权

• 404 返回 "未找到"。

• 301 返回 "永久移动"。

• 405 返回 "方法不允许"

这显示了端点的灵活性--不仅适用于错误代码，还适用于任何 HTTP 状态代码。 13:04时，Tim 确认这种方法非常适合测试前端应用程序如何处理不同的服务器响应。

虽然他考虑过将其命名为 /httpcode，但为了简单起见，他还是坚持使用 /error，因为它主要用于模拟错误条件。

功能增强概要

Tim 在视频的最后总结了 API 的改进：

• Slowdowns模拟真实世界中 API 响应的延迟。

• 错误模拟提供了针对几乎所有 HTTP 响应进行测试的灵活性。

• 这些功能使示例 API 更为强大，对实际测试场景非常有价值。

在 14:16，Tim 强调了这些工具对于测试应用程序在不同 API 状态（如延迟响应或各种服务器错误）下的行为的重要性。

下一步：API 的 Docker 化

虽然本视频中没有详细介绍，但 Tim 提示了下一步：将 API Docker 化。 这样，开发人员就可以在一个独立的 Docker 容器中本地运行示例 API，从而更方便地在不同环境中部署和共享。

最后的想法

在视频的最后，Tim 重申了他的承诺，即建立一个全面的示例 API，其中包括开发人员实际需要测试的功能。这些功能包括

• 延误

• 错误

• 健康检查

• 身份验证和高级端点的未来计划

我们的目标简单而有力--为开发人员提供一种能够模仿真实 API 怪癖的工具，从而使他们的应用程序稳健、可靠、用户友好。

结论

在本课结束时，观众将更好地理解如何以及为何在他们的 API 中引入人工延迟和错误响应。Tim Corey 的方法有条不紊、实用性强，并直接与现实世界的应用测试需求相联系。 如果您想提高 API 测试水平，本课将是您的绝佳参考资料--现在您知道该去哪里找了。

请观看 Tim Corey 制作的完整 视频课程，以获得实践指导。