协慌网

是否存在用于构造来自 API 的 JSON 响应的标准或最佳实践？显然，每个应用程序的数据都是不同的，因此您不必担心很多，而可以考虑 “响应样板”。我的意思是一个例子：

成功的请求：

{
  "success": true,
  "payload": {
    /* Application-specific data would go here. */
  }
}

请求失败：

{
  "success": false,
  "payload": {
    /* Application-specific data would go here. */
  },
  "error": {
    "code": 123,
    "message": "An error occurred!"
  }
}

是的，已经出现了一些标准（尽管对标准的定义有一些自由）：

1. JSON API -JSON API 还涵盖创建和更新资源，而不仅仅是响应。
2. JSend-简单，可能正在做的事情。
3. OData JSON 协议- 非常复杂。
4. HAL - OData 的一样，但目标是成为HATEOAS等。

还有 JSON API 描述格式：

• 昂首阔步
  • JSON 模式（由 swagger 使用，但您可以单独使用）
• JSON 中的 WADL
• 拉姆
• HAL 是因为HATEOAS在理论上是自我描述。

Google JSON 指南

成功响应返回data

{
  "data": {
    "id": 1001,
    "name": "Wing"
  }
}

错误响应返回error

{
  "error": {
    "code": 404,
    "message": "ID not found"
  }
}

如果您的客户是 JS，则可以使用if ("error" in response) {}来检查是否存在错误。

我想事实上的标准并没有真正出现（也许永远不会）。但是无论如何，这是我的看法：

成功的请求：

{
  "status": "success",
  "data": {
    /* Application-specific data would go here. */
  },
  "message": null /* Or optional success message */
}

请求失败：

{
  "status": "error",
  "data": null, /* or optional error payload */
  "message": "Error xyz has occurred"
}

优势：成功案例和错误案例中的顶级元素相同

缺点：没有错误代码，但是如果需要，可以将状态更改为（成功或失败）代码，或者 - 可以添加另一个名为 “code” 的顶级项。