“POST”验证失败的示例内容类型？

Question

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

例如，给定的要求

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，它实际上不是错误，而是重定向。这就是为什么你应该坚持一种内容类型。

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