假设我的 SemVer API 版本是 2.0.0
假设我有一个端点 /foo，它现在总是错误地返回一个 {200, "some message"} 或 {500, "some message "
我修复了一个错误，现在我可以检测到错误的请求，现在我返回 {200, "some message"} 或 {400, "some message"}或 {500, "some message"}
这是否被视为 SemVer 中的 API 重大更改？用户可能不期望 400，所以我可以看到 3.0.0 的情况，但是我也可以看到这应该一直是 BAD REQUEST 上的 400，因为在某种意义上“HTTP”是我的 API，因此对 2.0.1 进行了补丁修复，所以我很纠结。
最佳答案
我认为在回答这个问题之前，您必须从哲学上确定责任在哪里。也就是说，如果客户端代码无法处理新的(正确的)状态代码，那么这是否会破坏您更改的结果或客户端代码编写不当的结果。如果您之前在 500 响应中发送了一些有用的信息，那么可以合理地预期客户端代码可能依赖它。
对我来说，这听起来像是 minor 的定义改变:
MINOR version [is] when you add functionality in a backwards-compatible manner[. . .]
实际内部服务器错误依然正常发送，成功结果依然正常发送；您所做的只是为客户添加了确定错误发生位置的能力。
编辑:所以我相信这不是 2.0.1 或 3.0.0，而是 2.1.0.
关于http - 更具体的 HTTP 代码是 "Semver breaking change"吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41772332/