这是一个创建于 665 天前的主题，其中的信息可能已经有所发展或是发生改变。
例如： 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 友们你们更倾向于哪种方式，原因是什么
 | 1 28Sv0ngQfIE7Yloe 2024-03-15 11:07:55 +08:00 第一种，比较适合继承 第二种，比较适合组合 |
 | 2 nitmali 2024-03-15 11:08:23 +08:00 得看后端怎么处理的，个人倾向第二种，pageIndex ，pageSize 可以抽出来继承（我是前端） |
 | 3 iyiluo 2024-03-15 11:09:37 +08:00 第二个，结构化，你这字段比较少，遇到几百个字段的 json ，都塞在一层，就变成一坨了，分分钟变成屎山。 |
 | 4 sdwgyzyxy 2024-03-15 11:10:43 +08:00 第二种定义结构体比较好，而且可以拿任意一部分调用其他模块，所以，推荐第二种 |
 | 6 unt OP 然后这是 POST 的查询方法，对于更新类的方法，没有 pageIndex 和 pageSize ，这时候一个裸的 pBody 是否会很奇怪 |
 | 7 mysdemon 2024-03-15 11:17:45 +08:00  2 java 后端，1 和 2 都用过，一般的查询接口倾向于第一种，架构中有分页参数公共类，继承一下就可以了，第二种的继承要实现范类，名称要固定。如果公司没有规定确定的名称规范，建议用第一种 |
 | 8 chenliangngng 2024-03-15 11:24:59 +08:00 直接抄大厂解决方案就可以了，第二种 |
 | 9 siweipancc 2024-03-15 11:26:17 +08:00 via iPhone 分页属性必须抽象一层，方便互传。查询用第一种，继承。 |
| 10 unt OP @chenliangngng #8 在哪里可以看到大厂示例，我看到很多比如阿里云的公开接口，参数都是直接平铺裸露在外面的 |
 | 11 deepshe 2024-03-15 11:40:32 +08:00 之前见过分页属性放到 header 里，这样就不影响 body 了 |
 | 12 estk 2024-03-15 12:12:42 +08:00 via iPhone 楼主这种情况还不如用 graphql |
 | 13 KKKKKKKKKKKKKKKK 2024-03-15 12:14:19 +08:00 第二种 |
 | 14 wolfie 2024-03-15 12:19:23 +08:00 第一种 第二种写个接口看看，难受不难受。 |
 | 15 zhy0216 2024-03-15 12:22:29 +08:00 via Android 看 area type star 是否是同时存在或不存在 如果是的 第二种好 不是都可以 |
 | 16 BeautifulSoap 2024-03-15 12:22:38 +08:00 via Android @unt 你好，现实是一个请求有几百个字段是存在的。最近就接触到了一个几百个字段的项目 |
 | 18 wanniwa 2024-03-15 13:00:11 +08:00 第二种，因为你有的时候还是会返回 list 数据 { "pageIndex": 1, "pageSize": 10, "data": [{ "area": 1, "type": 1, "star": 1 },{ "area": 2, "type": 2, "star": 2 }] } |
| 19 wanniwa 2024-03-15 13:02:53 +08:00 如果是单条根据 id 查询的接口，那应该也不会有 pageIndex ，pageSize 这个两个分页字段了，就直接下面这样就行了 { "area": 2, "type": 2, "star": 2 } |
| 23 wanniwa 2024-03-15 13:21:25 +08:00 推荐第一种，抽一个通用 page 的父类就行，第二种谁写谁恶心，还要写一个组装对象的 class ，pBody 些得写一个 class |
 | 26 9fan 2024-03-15 14:14:57 +08:00 组合无疑比继承更加优雅，相对于 java |
 | 27 nekomiao 2024-03-15 14:19:28 +08:00 只有我是吧 page 参数放 urlPath 里的吗。。 ```java @PostMapping(value = "/getPage/{pageNo}/{pageSize}") public Result getPage(@RequestBody SelectVO selectVO, @PathVariable Integer pageNo, @PathVariable Integer pageSize) ``` |
 | 28 wu00 2024-03-15 14:30:51 +08:00 request 用 1 ，主要是 get 请求参数更优雅 response 用 2 ，结构优雅，更容易做泛型封装 |
 | 30 yrzs 2024-03-15 15:12:44 +08:00 组合优于继承 |
 | 31 yooomu 2024-03-15 15:21:48 +08:00 我用 GET 和 query 参数，所以可能偏向于第一种 |
 | 33 HappyAndSmile 2024-03-15 15:32:42 +08:00 第一种 |
| 34 unt OP @yooomu #31 query 的话确实第一种更加优雅，但是我们最开始定的规范是一个 get 方法都不用，全部用 post 方法放 json 里，所以才用了第二种。 |
 | 35 pannanxu 2024-03-15 17:12:45 +08:00 {"filter":{},"pageable":{"current":1,"pageSize":20}} |
 | 37 xavierchow 2024-03-15 20:27:37 +08:00 > 但是我们最开始定的规范是一个 get 方法都不用，全部用 post 方法放 json 里， 不知道为什么一开始定这样的规范，与其自己去定义一套新的，还不如去使用已被详细讨论过并被严格定义的行业规范，比如 https://jsonapi.org/format/#fetching |
| 38 unt OP @xavierchow 因为应用场景没有任何性能压力，并发不会超过 50 |
 | 39 AItsuki 2024-03-15 23:02:34 +08:00 第一种吧，本质上是一个 filter ，全部属性平铺就好了。第二种无论是客户端还是服务端都嫌麻烦 |
Select Language