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":"Email address not found!","code":"fielderror","field":"email","reason":"notfound"}（可简化为{"error":"...","code":"emailnotfound"}）

允许API开发人员正确地向用户呈现错误（并对错误采取行动），同时允许您在不破坏应用程序的情况下更改消息。它也真正有助于翻译错误消息，无论是在您的最终还是外部开发人员的最后。
另一种方法是简单地不返回任何正文，并使用HTTP标头告诉用户代理出了什么问题。例如，您可以使用X-Error和X-Error-Code来显示人类可读错误和机器可读代码。
创建太多内容类型可能是件坏事。我个人更喜欢始终使用application/json并通过查看HTTP代码让用户代理了解状态：200,400,403,404,500等。
绝对不要开始组合HTTP代码和内容类型。您不希望您的用户必须知道application/myapp/error表示存在错误，除非它是200，在这种情况下您处于编辑屏幕中，或者当它是302时，它实际上不是错误而是重定向。这就是为什么你应该坚持使用一种内容类型。

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