什么是 problem+json 以及为什么要使用它？

它是 RFC 9457 中标准化的错误格式：一小部分商定的字段，以便客户端和日志可以以相同的方式从任何 API 读取错误，而不是每个服务都发明自己的错误信封。

为什么 status 既出现在主体中又出现在响应中？

主体中的 status 反映了 HTTP 状态，以便被记录或转发的错误文档在与响应分离后仍然有意义。RFC 9457 要求两者一致，不匹配是一个值得断言的错误。

errors 数组是标准的一部分吗？

不是。RFC 9457 允许扩展成员（extension members），而 errors 是其中之一 —— 它是 GitHub 和 Stripe 风格的 API 通常会添加的字段级详细信息。您的客户端应将标准成员视为有保证的，而将扩展视为可选的。

模拟一个 RFC 9457 problem+json 错误

一个 GET 模拟（mock），返回按 RFC 9457 格式形成的 422 application/problem+json 验证错误。

RFC 9457 定义了 application/problem+json，一种标准的 HTTP 错误体结构，包含 type、title、status 和 detail。此模板返回带有字段级 errors 扩展的 422 问题文档，因此您可以针对该格式构建和测试错误处理，而不是针对您的后端恰巧在今天发出的无论什么临时 JSON。

代替第三方 API 端点。

响应负载

{"type":"https://quickmock.dev/problems/validation-error","title":"Your request parameters didn't validate","status":422,"detail":"The 'email' field must be a valid email address.","instance":"{{mock.url}}/requests/38f0","errors":[{"field":"email","message":"must be a valid email address"}]}

值得了解的字段

字段	含义
type	标识问题类型的 URI —— 它是一个文档地址，不一定是有效链接。
title	对该问题的简短的、人类可读的总结。
status	反映 HTTP 响应状态，保留在主体中以供单独记录它的客户端使用。
detail	对此次发生的具体解释；编辑它以匹配您正在测试的失败。
errors	带有字段级错误的非标准扩展数组，这类错误通常由 GitHub 或 Stripe 风格的 API 添加。

创建模拟数据

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 422,
  "content_type": "application/problem+json",
  "response_body": "{\"type\":\"https://quickmock.dev/problems/validation-error\",\"title\":\"Your request parameters didn't validate\",\"status\":422,\"detail\":\"The 'email' field must be a valid email address.\",\"instance\":\"{{mock.url}}/requests/38f0\",\"errors\":[{\"field\":\"email\",\"message\":\"must be a valid email address\"}]}"
}'

调用它

curl https://quickmock.dev/m/<slug>

您将获得什么

GET /m/<slug> -> 422 application/problem+json
an RFC 9457 problem document with a custom errors[] extension

这与真实情况有何不同

这是一个固定的验证错误 —— status、detail 和 errors[] 扩展都是硬编码的，因此请编辑响应主体来重现您的客户端需要处理的特定失败情况，而不是泛泛的 422。

来源

常见问题解答

什么是 problem+json 以及为什么要使用它？: 它是 RFC 9457 中标准化的错误格式：一小部分商定的字段，以便客户端和日志可以以相同的方式从任何 API 读取错误，而不是每个服务都发明自己的错误信封。
为什么 status 既出现在主体中又出现在响应中？: 主体中的 status 反映了 HTTP 状态，以便被记录或转发的错误文档在与响应分离后仍然有意义。RFC 9457 要求两者一致，不匹配是一个值得断言的错误。
errors 数组是标准的一部分吗？: 不是。RFC 9457 允许扩展成员（extension members），而 errors 是其中之一 —— 它是 GitHub 和 Stripe 风格的 API 通常会添加的字段级详细信息。您的客户端应将标准成员视为有保证的，而将扩展视为可选的。

准备好使用了吗？

在模拟构建器中打开以先进行调整

与本指南非常搭配：模拟特定的错误响应