1

假设 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"
}

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

4

1 回答 1

1

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

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

    {"error":"Email address not found!","code":"fielderror","field":"email","reason":"notfound"}（可以简化为{"error":"...","code":"emailnotfound"}）

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

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

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

于 2012-04-23T14:37:08.413 回答