validation - `POST` 验证失败的示例内容类型？

Question

假设 HTTP 服务器使用 400 响应代码响应 POST，因为请求验证失败(例如，找不到电子邮件地址)。如果服务器希望向客户端提供有关错误性质的更多信息，应该如何返回？对于请求中使用的每种可能的内容类型，理想情况下是否应该有关联的“错误”内容类型？

例如给定请求

POST /users
Content-Type: application/x-myuser

{
    "email": "foo@example.com",
    "name": "Michael"
}

一个回应可能是

400 Bad Request
Content-Type: application/x-myuser-error

{
    "email": "Email address foo@example.com not found"
}

是否有公开可用的“错误”内容类型的好例子？

Answer 1

我没有任何例子，但最好始终牢记这些:

• 始终包含机器可读的错误，并尽可能概括。像这样的 JSON 结构

  {"error":"找不到电子邮件地址!","code":"fielderror","field":"email","re​​ason":"notfound"}(可能是简化为 {"error":"...","code":"emailnotfound"})

  允许 API 开发人员将错误正确地呈现给用户(并针对错误采取行动)，同时允许您在不破坏应用程序的情况下更改消息。它也确实有助于翻译错误消息，无论是在您端还是在外部开发人员端。

• 另一种方法是不返回任何正文，并使用 HTTP header 告诉用户代理出了什么问题。例如，您可以使用 X-Error 和 X-Error-Code 来显示人类可读的错误和机器可读的代码。
• 创建过多的内容类型可能是一件坏事。我个人更喜欢始终使用 application/json 并通过查看 HTTP 代码让用户代理了解状态:200、400、403、404、500 等。
• 绝对不要开始组合 HTTP 代码和内容类型。你不希望你的用户必须知道 application/myapp/error 意味着有错误，除非它是 200，在这种情况下你在编辑屏幕，或者当它是 302 它实际上不是错误但重定向。这就是为什么您应该坚持使用一种内容类型。

底线:始终保持简单。确保在检测状态时必须查看一个字段，而不是两个或三个。一旦用户代理确定了状态，它就可以选择查看其他一些字段以获取额外信息，但前提是它确定出了问题。包含单独的内容类型可能无济于事。