修好接手过来的 API

目标

接手一个测试和文档都不可信的 API 后，仅根据症状找出并修复四个缺陷。

为什么重要

本练习中的缺陷全都属于返回 200 却给出错误值的类型。抛出异常的错误会被监控发现，而返回貌似合理数字的错误，往往要到几个月后账务对不上时才会暴露。因此，需要先将规范整理成输入输出表，再测试边界值。

最后一步中的状态码区分也不是装饰。400 表示“你发送的内容有误”，500 表示“我在处理时出错”，而大多数客户端库只会重试 5xx。若对错误参数返回 500，一个注定失败的请求就会被无限重试，只会增加服务器负载。状态码是供机器读取的约定，而不是给人看的说明。

/opt/app/server.py 的 docstring 中写有原始规范。代码与该规范不一致的地方，就是缺陷列表。

步骤

1. 将 /opt/app/server.py 复制到 /root/app/server.py。之后只修改该副本。
2. 运行副本，使 127.0.0.1:8000/health 能够响应。
3. 修复 /sum?a=2&b=3，使其返回 5。
4. 确认 /sum?a=10&b=32 返回 42，/sum?a=-4&b=9 返回 5。
5. 修复 /avg?nums=2,4,9，使其返回 5；修复 /avg?nums=10，使其返回 10。平均值向下取整。
6. 修复 /upper?s=fde，使其返回 FDE。
7. 修复 /orders/total，使其返回 200 和 130400。有效行的条件写在 docstring 中。
8. 使 /sum?a=2 和 /sum?a=x&b=1 分别返回 400。原始代码已经会为 /nope 返回 404，因此只需确认——需要修复的只有 /sum 的参数处理。先测量哪些功能已经正常，是本步骤的要点。

参考

• 修复后必须重启服务器才能生效。执行 kill %1 后重新启动，或使用 pkill -f server.py。
• 可通过 curl -s -o /dev/null -w '%{http_code}\n' URL 只查看状态码。
• 常见错误 1：直接修改 /opt/app/server.py 原始文件。评分只检查 8000 端口的行为，但养成不改动客户文件的习惯，在实际现场更为重要。
• 常见错误 2：第 7 步从文件中删除损坏的行。数据应保持原样，由代码进行过滤。

创建工作副本

将 /opt/app/server.py 复制到 /root/app/server.py。之后只修改该副本。

不直接修改原始文件是现场工作的基本原则。将 /opt/app/server.py 复制到 /root/app/ 下。

启动服务器

运行副本，使 127.0.0.1:8000/health 能够响应。

使用 python3 运行后，它会在 127.0.0.1:8000 上监听。每次修改后都必须重启才能生效。

修正加法结果

修复 /sum?a=2&b=3，使其返回 5。

观察输入 2 和 3 时得到的值，就能立即看出使用了哪一种运算符。在文件中找到并修正那一个字符。

同时检查负数输入

确认 /sum?a=10&b=32 返回 42，/sum?a=-4&b=9 返回 5。

这是检查边界值的步骤。确认正负号混合时结果也正确，才能判断它是否真的是加法。

修正平均值计算

修复 /avg?nums=2,4,9，使其返回 5；修复 /avg?nums=10，使其返回 10。平均值向下取整。

分别测试三个元素和一个元素的情况。这样会暴露除数与元素数量相差多少。

修正大小写转换

修复 /upper?s=fde，使其返回 FDE。

检查端点名称与实际调用的字符串方法是否一致。

使订单总额计算不再失败

修复 /orders/total，使其返回 200 和 130400。有效行的条件写在 docstring 中。

docstring 中列出了有效行的三个条件，但代码中没有对应的分支。按文档规则过滤即可。

对错误请求返回正确状态码

使 /sum?a=2 和 /sum?a=x&b=1 分别返回 400。原始代码已经会为 /nope 返回 404，因此只需确认——需要修复的只有 /sum 的参数处理。先测量哪些功能已经正常，是本步骤的要点。

参数缺失或不是数字时，服务器目前会崩溃。客户端错误应返回 4xx。