V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
unt
V2EX  ›  程序员

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

  •  
  •   unt · 285 天前 · 5275 次点击
    这是一个创建于 285 天前的主题,其中的信息可能已经有所发展或是发生改变。

    例如: 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 友们你们更倾向于哪种方式,原因是什么

    40 条回复    2024-03-16 12:27:46 +08:00
    28Sv0ngQfIE7Yloe
        1
    28Sv0ngQfIE7Yloe  
       285 天前
    第一种,比较适合继承

    第二种,比较适合组合
    nitmali
        2
    nitmali  
       285 天前
    得看后端怎么处理的,个人倾向第二种,pageIndex ,pageSize 可以抽出来继承(我是前端)
    iyiluo
        3
    iyiluo  
       285 天前
    第二个,结构化,你这字段比较少,遇到几百个字段的 json ,都塞在一层,就变成一坨了,分分钟变成屎山。
    sdwgyzyxy
        4
    sdwgyzyxy  
       285 天前
    第二种定义结构体比较好,而且可以拿任意一部分调用其他模块,所以,推荐第二种
    unt
        5
    unt  
    OP
       285 天前
    @iyiluo #3 现实情况是没有几百个字段的情况,最多不超过 20 个。现在要定统一规范,在此之前我司是两种并行的
    unt
        6
    unt  
    OP
       285 天前
    然后这是 POST 的查询方法,对于更新类的方法,没有 pageIndex 和 pageSize ,这时候一个裸的 pBody 是否会很奇怪
    mysdemon
        7
    mysdemon  
       285 天前   ❤️ 2
    java 后端,1 和 2 都用过,一般的查询接口倾向于第一种,架构中有分页参数公共类,继承一下就可以了,第二种的继承要实现范类,名称要固定。如果公司没有规定确定的名称规范,建议用第一种
    chenliangngng
        8
    chenliangngng  
       285 天前
    直接抄大厂解决方案就可以了,第二种
    siweipancc
        9
    siweipancc  
       285 天前 via iPhone
    分页属性必须抽象一层,方便互传。查询用第一种,继承。
    unt
        10
    unt  
    OP
       285 天前
    @chenliangngng #8 在哪里可以看到大厂示例,我看到很多比如阿里云的公开接口,参数都是直接平铺裸露在外面的
    deepshe
        11
    deepshe  
       285 天前
    之前见过分页属性放到 header 里,这样就不影响 body 了
    estk
        12
    estk  
       285 天前 via iPhone
    楼主这种情况还不如用 graphql
    KKKKKKKKKKKKKKKK
        13
    KKKKKKKKKKKKKKKK  
       285 天前
    第二种
    wolfie
        14
    wolfie  
       285 天前
    第一种
    第二种写个接口看看,难受不难受。
    zhy0216
        15
    zhy0216  
       285 天前 via Android
    看 area type star 是否是同时存在或不存在
    如果是的 第二种好
    不是都可以
    BeautifulSoap
        16
    BeautifulSoap  
       285 天前 via Android
    @unt 你好,现实是一个请求有几百个字段是存在的。最近就接触到了一个几百个字段的项目
    unt
        17
    unt  
    OP
       285 天前 via iPhone
    @zhy0216 新增和编辑的时候是同时存在,查询的时候是可能存在可能不存在
    wanniwa
        18
    wanniwa  
       285 天前
    第二种,因为你有的时候还是会返回 list 数据
    {
    "pageIndex": 1,
    "pageSize": 10,
    "data": [{
    "area": 1,
    "type": 1,
    "star": 1
    },{
    "area": 2,
    "type": 2,
    "star": 2
    }]
    }
    wanniwa
        19
    wanniwa  
       284 天前
    如果是单条根据 id 查询的接口,那应该也不会有 pageIndex ,pageSize 这个两个分页字段了,就直接下面这样就行了
    {
    "area": 2,
    "type": 2,
    "star": 2
    }
    unt
        20
    unt  
    OP
       284 天前
    @wanniwa #18 你这是返回,我指的是请求,返回不会是这样返的
    unt
        21
    unt  
    OP
       284 天前
    @wanniwa #19 不能因为有 pageIndex 和 pageSize 就包,没有就不包吧,不统一了
    wanniwa
        22
    wanniwa  
       284 天前
    @unt #21 哦哦,我看错了
    wanniwa
        23
    wanniwa  
       284 天前
    推荐第一种,抽一个通用 page 的父类就行,第二种谁写谁恶心,还要写一个组装对象的 class ,pBody 些得写一个 class
    wanniwa
        24
    wanniwa  
       284 天前
    @wanniwa #22 pBody 也得写一个 class
    wanniwa
        25
    wanniwa  
       284 天前
    @wanniwa pBody 也得写一个 class
    9fan
        26
    9fan  
       284 天前
    组合无疑比继承更加优雅,相对于 java
    nekomiao
        27
    nekomiao  
       284 天前
    只有我是吧 page 参数放 urlPath 里的吗。。
    ```java
    @PostMapping(value = "/getPage/{pageNo}/{pageSize}")
    public Result getPage(@RequestBody SelectVO selectVO, @PathVariable Integer pageNo, @PathVariable Integer pageSize)
    ```
    wu00
        28
    wu00  
       284 天前
    request 用 1 ,主要是 get 请求参数更优雅

    response 用 2 ,结构优雅,更容易做泛型封装
    unt
        29
    unt  
    OP
       284 天前
    @nekomiao #27 现在大部分路由参数用得很少,主流还是 query 和 body
    yrzs
        30
    yrzs  
       284 天前
    组合优于继承
    yooomu
        31
    yooomu  
       284 天前
    我用 GET 和 query 参数,所以可能偏向于第一种
    sunpj
        32
    sunpj  
       284 天前
    @nekomiao 一般很少这么写吧
    HappyAndSmile
        33
    HappyAndSmile  
       284 天前
    第一种
    unt
        34
    unt  
    OP
       284 天前
    @yooomu #31 query 的话确实第一种更加优雅,但是我们最开始定的规范是一个 get 方法都不用,全部用 post 方法放 json 里,所以才用了第二种。
    pannanxu
        35
    pannanxu  
       284 天前
    {"filter":{},"pageable":{"current":1,"pageSize":20}}
    unt
        36
    unt  
    OP
       284 天前
    @pannanxu #35 有点丑
    xavierchow
        37
    xavierchow  
       284 天前
    > 但是我们最开始定的规范是一个 get 方法都不用,全部用 post 方法放 json 里,

    不知道为什么一开始定这样的规范,与其自己去定义一套新的,还不如去使用已被详细讨论过并被严格定义的行业规范,比如 https://jsonapi.org/format/#fetching
    unt
        38
    unt  
    OP
       284 天前 via iPhone
    @xavierchow 因为应用场景没有任何性能压力,并发不会超过 50
    AItsuki
        39
    AItsuki  
       284 天前
    第一种吧,本质上是一个 filter ,全部属性平铺就好了。第二种无论是客户端还是服务端都嫌麻烦
    changdy
        40
    changdy  
       284 天前
    @nekomiao 卧槽 大兄弟 你这是走到哪 都是异教徒啊...
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3439 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 05:01 · PVG 13:01 · LAX 21:01 · JFK 00:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.