有没有关于从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 的描述格式：
成功响应返回data
{
"data": {
"id": 1001,
"name": "Wing"
}
}
错误响应返回 error
{
"error": {
"code": 404,
"message": "ID not found"
}
}
如果你的客户端是 JS，你可以使用 if ("error" in response) {} 来检查是否有错误。
error 上的链接，谷歌页面会给出一个例子。 - user4698348{
"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”的顶级项。
messages的字段，它是消息数组，而不是单个字符串。 - StockBreakstatus === 200，那么你可能没有理解HTTP状态码的意义。浏览器原生的 fetch API 响应包括一个布尔值 ok，用于指示是否返回了任何非成功状态。您始终可以使用比较运算符检查任何在 2XX 范围之外的内容。Swagger/OpenAPI 建议使用状态码报告错误: https://swagger.io/blog/api-design/api-design-best-practices/#responses - Jon Hieb仅使用HTTP状态码来指示是否出现错误，并尝试限制自己使用标准代码（通常应该足够）。
使用HTTP状态码+json body（即使是错误）。为错误定义统一的结构（例如：code、message、reason、type等），并将其用于错误，如果是成功，则返回预期的json响应。
忘记HTTP状态码（例如：始终为状态200），始终使用json，并在响应的根部添加一个布尔值responseValid和一个错误对象（code、message等），如果是错误，则填充它，否则填充其他字段（成功）。
优点：客户端只处理响应的主体，它是一个json字符串，并忽略状态（？）。
缺点：标准性较低。
由你决定 :)
根据API的不同，我会选择2或3（我更喜欢用于json rest api的2）。 在设计REST API时，我还经历过为每个资源（URL）编写文档的重要性：参数、正文、响应、标头等+示例。
我还建议您使用jersey（jax-rs实现）+ genson（java / json数据绑定库）。 您只需将genson + jersey放入类路径中，即可自动支持json。
编辑：
解决方案2最难实现，但优点是可以很好地处理异常而不仅仅是业务错误，初始工作量更重要，但长期来看会更有优势。
解决方案3对于服务器端和客户端都很容易实现，但它并不像你希望的那样好，因为你必须将要返回的对象封装在包含响应有效性+错误的响应对象中。
目前，RFC 7807: HTTP API问题细节是我们所拥有的最接近官方标准的东西。
以下是Instagram使用的JSON格式：
{
"meta": {
"error_type": "OAuthException",
"code": 400,
"error_message": "..."
}
"data": {
...
},
"pagination": {
"next_url": "...",
"next_max_id": "13872296"
}
}
我不会傲慢到声称这是一个标准，所以我将使用“我更喜欢”的形式。
在我的设计中，当请求文章列表时，我更喜欢简洁的响应（返回文章的JSON数组）。
我使用HTTP进行状态报告。 200 只返回有效载荷。
400 返回请求出错的消息：
{"message" : "Missing parameter: 'param'"}
如果模型/控制器/URI不存在，则返回404。
如果在我的一侧处理时出现错误，则返回带有消息的501。
{"message" : "Could not connect to data store."}
根据我所看到的，相当多的REST-ish框架往往沿这个方向。
理念:
JSON被认为是一种负载格式，它不是一个会话协议。冗长的会话样式负载的整个想法来自XML/SOAP世界和各种误导性选择，这些选择导致了那些臃肿的设计。在我们意识到所有这一切都是一个巨大的头痛之后，REST/JSON的整个重点就是要简化它，并坚持HTTP。我认为在JSend中没有任何标准可言，尤其是其中更冗长的部分。XHR将对HTTP响应做出反应，如果您使用jQuery进行AJAX（大多数人都这样做），您可以使用try/catch和done()/fail()回调来捕获错误。我无法看出将状态报告封装在JSON中是否比那更有用。
{
"description" : "Validation Failed"
"errors" : [ {
"field" : "phoneNumber",
"message" : "Invalid phone number."
} ],
}
重要的部分是"field"属性必须精确匹配无法验证的JSON字段。这允许客户端准确地了解其请求出了什么问题。此外，"message"是请求的区域设置语言。如果“emailAddress”和“phoneNumber”都无效，则“errors”数组将包含两者的条目。 409（冲突）JSON响应体可能如下所示：
{
"description" : "Already Exists"
"errors" : [ {
"field" : "phoneNumber",
"message" : "Phone number already exists for another user."
} ],
}
通过HTTP状态码和这个JSON，客户端具备了响应错误的确定性方式，而不会创建一个试图完全替代HTTP状态码的新错误标准。需要注意的是，这些仅适用于400错误范围内的任何内容。对于200范围内的任何内容，我只需返回适当的内容即可。对于我来说，通常是一种类似HAL的JSON对象，但在这里并不重要。
我考虑增加的一件事是在“errors”数组条目或JSON对象本身的根中添加数字错误代码。但到目前为止我们还没有需要它。
谷歌、Facebook、Twitter和亚马逊等大型软件公司的REST API响应格式没有达成一致，虽然在上面的回答中提供了许多链接，有些人试图标准化响应格式。
由于API的需求可能不同，很难让每个人都接受某种格式。如果你有数百万用户使用你的API，你为什么要改变你的响应格式呢？
以下是我基于谷歌、Twitter、亚马逊和一些互联网帖子的响应格式思路:
https://github.com/adnan-kamili/rest-api-response-format
Swagger文件: