是否存在从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-RPC 2.0定义了一种标准的请求和响应格式,在使用REST API之后,它是一股新鲜空气。

其他回答

除了常识之外,没有违法或非法的标准。如果我们像两个人说话一样抽象这一点,那么标准就是他们在最短时间内用最少的语言准确理解对方的最佳方式。在我们的例子中,“最小单词”是优化带宽以提高传输效率,而“准确理解”是提高解析器效率的结构;这最终导致数据越少,结构越常见;以便它可以穿过针孔并且可以通过公共范围(至少最初)解析。

几乎在所建议的每一种情况下,我都会看到“成功”和“错误”场景的单独响应,这对我来说有点模糊。如果这两种情况下的响应不同,那么为什么我们真的需要在那里设置“成功”标志呢?不存在“错误”是否意味着“成功”?“成功”为TRUE且设置了“错误”时,是否可能有响应?或者,如果没有设置“错误”,则“成功”为FALSE?仅仅一个旗帜是不够的?我更希望只有“错误”标志,因为我相信“错误”比“成功”少。

此外,我们真的应该将“错误”设置为标志吗?如果我想回复多个验证错误怎么办?因此,我发现有一个“Error”节点更有效,每个错误都是该节点的子节点;其中空的(计数为零)“错误”节点表示“成功”。

Google JSON指南

成功响应返回数据

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

错误响应返回错误

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

如果您的客户端是JS,则可以使用if(响应中的“error”){}来检查是否存在错误。

是的,出现了一些标准(尽管在标准定义上有些自由):

JSON API-JSON API还包括创建和更新资源,而不仅仅是响应。JSend-简单,可能是您已经在做的事情。OData JSON协议-非常复杂。哈尔-像OData,但目标是像HATEOAS。

还有JSON API描述格式:

大摇大摆JSON模式(swagger使用,但可以单独使用)JSON格式的WADL冲压,冲压HAL,因为理论上HATEOAS是自我描述的。

有点晚了,但这是我对HTTP错误响应的看法,我发送代码(通过状态)、通用消息和详细信息(如果我想提供特定端点的详细信息,有些是不言自明的,因此不需要详细信息,但它可以是自定义消息,甚至可以是完整的堆栈跟踪,具体取决于用例)。为了成功,数据属性中的格式、代码、消息和任何数据都是类似的。

ExpressJS响应示例:

// Error

    res
      .status(422)
      .json({
        error: {
          message: 'missing parameters',
          details: `missing ${missingParam}`,
        }
      });
        
    // or
        
    res
      .status(422)
      .json({
        error: {
          message: 'missing parameters',
          details: 'expected: {prop1, prop2, prop3',
        }
      });

 // Success

    res
      .status(200)
      .json({
         message: 'password updated',
         data: {member: { username }}, // [] ...
      });

他们对大型软件巨头(谷歌、脸书、推特、亚马逊等)的rest api响应格式没有达成一致,尽管上面的答案中提供了许多链接,一些人已经尝试将响应格式标准化。

由于API的需求可能不同,很难让每个人都加入并同意某种格式。如果您有数百万用户使用您的API,为什么要更改响应格式?

以下是我对谷歌、推特、亚马逊和互联网上一些帖子的回应格式的看法:

https://github.com/adnan-kamili/rest-api-response-format

交换文件:

https://github.com/adnan-kamili/swagger-sample-template