当前位置: 首页 > 知识库问答 >
问题:

REST在API响应中返回json数组的最佳实践?[已关闭]

贺文彬
2023-03-14

想改进这个问题吗 更新问题,通过编辑这篇文章,可以用事实和引用来回答。

API响应应该始终是JSON对象,键和值是json数组吗?因此:

{
    "foo": [
        {
            "scope": "abcd",
            "allowed": [
                "abc"
            ],
            "denied": [
                "123"
            ]
        },
        {
            "scope": "abcd",
            "allowed": [
                "abc"
            ],
            "denied": [
                "123"
            ]
        }
    ]
}

或者 API 响应本身可以只是一个数组?我找不到这方面的最佳实践是什么,如果一个被认为是一个糟糕的方法。

[
  {
    "scope": "abcd",
    "allowed": [
      "abc"
    ],
    "denied": [
      "123"
    ]
  },
  {
    "scope": "abcd",
    "allowed": [
      "abc"
    ],
    "denied": [
      "123"
    ]
  }
]

共有1个答案

西门旻
2023-03-14

我认为第一个选项更适合大多数情况,遵循始终返回JSON对象的原则。

这意味着您的所有客户端(web、桌面或移动)都可以期望所有endpoint返回一个JSON对象。这种方法允许您在不破坏任何客户端应用程序或版本控制的情况下扩展对象,例如,您想要为有问题的数组添加元数据。

 类似资料:
  • 我的应用程序与一些外部服务集成,并向该服务请求数据。我只是想知道在客户端建模响应的最佳实践是什么,尤其是在客户端业务逻辑只需要一些数据的情况下。我正在考虑以下实施: 将JSON转换为包含所有数据/属性的类对象,并在我的代码中使用此类对象 将JSON转换为仅包含进一步处理所需的数据/属性的类对象 以上两者的组合(创建包含所有属性的类对象,然后将其转换为仅包含进一步业务逻辑所需属性的对象)

  • 我试图遵循API的最佳实践,但我得到了相互矛盾的建议。大多数人建议对URI使用脊柱病例(例如stackoverflow和RFC3986。我有一个API,允许通过各种参数过滤GET请求: < code >获取/终结点?my-parameter=true 但是,我也在 GET 响应和 PATCH 请求中使用相同的参数。在那里,我看到更多的骆驼大小写或snake_case,脊柱大小写是一个额外的语言,不

  • 我想回复ResponseEntity的回复。我对在ResponseEntity中提到返回类型的最佳实践有点困惑。 这是我的控制器: 我的主要责任: 这里我的返回类型是GenericResponse、AdminAccount。在ResponseEntity中提及所有退货类型是否是一种良好的做法? 哪个是最好的方法

  • 我担心我们返回错误给客户的方式。 我们是否在收到错误时通过抛出HttpResponseException立即返回错误: 或者累积所有错误,然后发送回客户端: 这只是一个示例代码,验证错误或服务器错误都无关紧要,我只是想知道最佳实践,每种方法的优缺点。

  • 假设我有这条路线 第一个示例将调用中的函数,但第二个示例我不知道将函数放在哪里,无论是在还是中,我是否应该将第二个示例放在中?还是在销毁功能中显示DiscountController?哪一种是最佳实践?

  • 为了尊重REST原则的最佳实践,是否最好在POST/PUT时返回创建/更新的实体?还是用Location头返回一个空的HTTP体? 更准确地说,当一个资源由一个帖子创建时,我们应该返回: 状态201位置标头(HTTP正文中创建的实体) 或 状态 201 位置标头(空正文) 当一个资源被PUT更新时,我们是否应该返回: 状态200(HTTP主体中的更新实体) 或 状态 204(空正文)