一个好的 error response 做两件事：它使用正确的 HTTP status code（机器可读的信号），并返回一个一致、有结构的 body，让开发者能据此行动。不一致的 error 形状是 client 侧最大的痛苦来源之一。
RFC 7807 定义了一个标准的“problem details” body，配有专用的 media type，因此你 API 中的每个错误看起来都一样：
HTTP/1.1 404 Not Found
Content-Type: application/problem+json
{
"type": "https://api.example.com/errors/not-found",
"title": "Resource not found",
"status": 404,
"detail": "No user exists with id 999",
"instance": "/users/999"
}
type —— 一个标识错误类别的 URI（可解引用到文档）。title —— 一个简短、人类可读的摘要（按 type 稳定）。status —— HTTP status，为方便而镜像一份。detail —— 针对本次发生的具体解释。instance —— 它发生在哪个请求/资源上。对于表单/字段校验，返回 422（或 400）以及一个字段错误的数组，这样 client 能在一遍内高亮出每个有问题的字段——而不是一次一个错误：
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json
{
"type": "https://api.example.com/errors/validation",
"title": "Validation failed",
"status": 422,
"errors": [
{ "field": "email", "code": "invalid_format", "message": "must be a valid email" },
{ "field": "age", "code": "out_of_range", "message": "must be >= 18" }
]
}
✓ Same body shape for every error (one code path on the client)
✓ A stable machine-readable code (type/code) — clients branch on this, not on prose
✓ Human-readable message for developers/logs
✗ Never leak stack traces, SQL, or internal paths to clients
错误设计是 API 在真实世界中悄悄成功或失败之处：顺利路径很容易，但使用者的大部分调试时间花在错误路径上，而一个不一致或含糊的错误契约会让集成变得痛苦。面试官用它检查两件事。其一，status code 加有结构的 body 协同工作——status 是给工具和 retry 的粗粒度信号，body 承载可据以行动的细节——而不是 200 OK 里塞个错误的反模式。其二，一个稳定、机器可读的 error code（通过 RFC 7807 的 type 或一个 code 字段），使 client 能基于 "insufficient_funds" 分支，而不是去字符串匹配一句可能被改写或本地化的英文 message。一次返回所有校验错误、并且绝不泄露诸如 stack trace 之类的内部细节，会让一个回答变得完整，表明你构建过其他团队真的要去使用的 API。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠