是否存在从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!"
}
}
当前回答
是的，出现了一些标准（尽管在标准定义上有些自由）：
JSON API-JSON API还包括创建和更新资源，而不仅仅是响应。JSend-简单，可能是您已经在做的事情。OData JSON协议-非常复杂。哈尔-像OData，但目标是像HATEOAS。
还有JSON API描述格式：
大摇大摆JSON模式（swagger使用，但可以单独使用）JSON格式的WADL冲压，冲压HAL，因为理论上HATEOAS是自我描述的。
其他回答
RFC 7807：HTTP API的问题细节是目前最接近官方标准的内容。
JSON-RPC 2.0定义了一种标准的请求和响应格式，在使用REST API之后，它是一股新鲜空气。
我想事实上的标准还没有真正出现（可能永远不会）。但无论如何，我的看法是：
成功的请求：
{
"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"
}
优势：成功和错误案例中的顶级元素相同
缺点：没有错误代码，但如果您愿意，您可以将状态更改为（成功或失败）代码，或者-您可以添加另一个名为“代码”的顶级项。
是的，出现了一些标准（尽管在标准定义上有些自由）：
JSON API-JSON API还包括创建和更新资源，而不仅仅是响应。JSend-简单，可能是您已经在做的事情。OData JSON协议-非常复杂。哈尔-像OData，但目标是像HATEOAS。
还有JSON API描述格式：
大摇大摆JSON模式（swagger使用，但可以单独使用）JSON格式的WADL冲压，冲压HAL，因为理论上HATEOAS是自我描述的。
我将此结构用于REST API：
{
"success": false,
"response": {
"data": [],
"pagination": {}
},
"errors": [
{
"code": 500,
"message": "server 500 Error"
}
]
}
