Body 传参时，有没有必要将查询参数用一个字段包起来

[unt]

例如： POST /api/client

1. Body 参数
{
  pageIndex:1,
  pageSize:10,
  area:123,
  type:1,
  star:1
}

2. Body 参数
{
  pageIndex:1,
  pageSize:10,
  pBody:{
    area:1,
    type:1,
    star:1
  }
}

哪种方式比较好，我知道都可以，只是习惯问题，但是应该是有一些历史遗留原因或者道理的，可能是语言间的开发差异导致，可能是开发人员的习惯导致，可能是由。。。。。。。

请问 V 友们你们更倾向于哪种方式，原因是什么

[Morii]

第一种，比较适合继承

第二种，比较适合组合

[nitmali]

得看后端怎么处理的，个人倾向第二种，pageIndex ，pageSize 可以抽出来继承（我是前端）

[iyiluo]

第二个，结构化，你这字段比较少，遇到几百个字段的 json ，都塞在一层，就变成一坨了，分分钟变成屎山。

[sdwgyzyxy]

第二种定义结构体比较好，而且可以拿任意一部分调用其他模块，所以，推荐第二种

[unt]

@iyiluo #3 现实情况是没有几百个字段的情况，最多不超过 20 个。现在要定统一规范，在此之前我司是两种并行的

[unt]

然后这是 POST 的查询方法，对于更新类的方法，没有 pageIndex 和 pageSize ，这时候一个裸的 pBody 是否会很奇怪

[mysdemon]

java 后端，1 和 2 都用过，一般的查询接口倾向于第一种，架构中有分页参数公共类，继承一下就可以了，第二种的继承要实现范类，名称要固定。如果公司没有规定确定的名称规范，建议用第一种

[chenliangngng]

直接抄大厂解决方案就可以了，第二种

[siweipancc]

分页属性必须抽象一层，方便互传。查询用第一种，继承。

[unt]

@chenliangngng #8 在哪里可以看到大厂示例，我看到很多比如阿里云的公开接口，参数都是直接平铺裸露在外面的

[deepshe]

之前见过分页属性放到 header 里，这样就不影响 body 了

[estk]

楼主这种情况还不如用 graphql

[KKKKKKKKKKKKKKKK]

第二种

[wolfie]

第一种
第二种写个接口看看，难受不难受。

[zhy0216]

看 area type star 是否是同时存在或不存在
如果是的 第二种好
不是都可以

[BeautifulSoap]

@unt 你好，现实是一个请求有几百个字段是存在的。最近就接触到了一个几百个字段的项目

[unt]

@zhy0216 新增和编辑的时候是同时存在，查询的时候是可能存在可能不存在

[wanniwa]

第二种，因为你有的时候还是会返回 list 数据
{
"pageIndex": 1,
"pageSize": 10,
"data": [{
"area": 1,
"type": 1,
"star": 1
},{
"area": 2,
"type": 2,
"star": 2
}]
}

[wanniwa]

如果是单条根据 id 查询的接口，那应该也不会有 pageIndex ，pageSize 这个两个分页字段了，就直接下面这样就行了
{
"area": 2,
"type": 2,
"star": 2
}

[unt]

@wanniwa #18 你这是返回，我指的是请求，返回不会是这样返的