跳至主要內容

接口数据类型(新对接方式)

blade基础框架大约 3 分钟约 929 字

接口数据类型新对接方式

正如序列化策略所说 每一门编程语言都有多种基础类型，而且每一种类型都有自己的特点和适用场景,后端不再限制和隐藏数据真实类型，避免给前后端双方对接增加不必要的麻烦。

如下： 前端需要关注的类型配置如下：

  1. 针对Long类型的序列化策略：转换为String类型返回前端，避免前端精度丢失

  2. 针对时间类型(Date、LocalDate、LocalDateTime)的序列化策略：转换为时间戳返回前端(也同样支持时间明文传输，这是时间类型的特殊性)

  3. 属性本身无值的null原样返回

    null就是指代的该字段只声明了类型，但是没有赋值！！！！

    和字符串的 "" 是不一样的

    新一代的编程语言(rust、kotlin、typescript)已经有足够的空安全特性(几乎都是使用?定义可空[可选])，所以null可以有独特的使用场景!!

对于前端的变化

上面的文字并不直观 来直观感受下

原始json数据

假设原始的数据json如下：

{
  "longId": "100861008610086",     // 注意这里的long类型  先假设是返回的字符串 
  "strUsername": "strUsername_37bfeda2694b",
  "strCellphone": "strCellphone_d7f281c67ad3",
  "boolActivated": false,
  "intAge": 1,
  "doubleBalance": 1.00,
  "bigDecimalHeightInMeters": 2.01,
  "listPermissions": [
    "listPermissions_83e883b91d02",
    "dnsajdnjksadnksjad",
    "this is ele in list"
  ],
  "emptyFavoriteNumbers": [
    10086,10000,18897
  ],
  "localDateTimeBirthDate": "2024-01-05 14:59:13",
  "localDateSignUpDate": "2024-01-05",
  "mapGenericInfo": {"mapkey":31232,"mapkey2": "this is str"},
  "nullStr": null
}

旧有后端返回

在以前的后端序列化方式，会返回如下结果：

{
  "successful": true,
  "code": "200",
  "message": "请求成功",
  "data": {
    "longId": "100861008610086", //真实类型是Long
    "strUsername": "strUsername_37bfeda2694b",
    "strCellphone": "strCellphone_d7f281c67ad3",
    "boolActivated": false,
    "intAge": "1", //真实类型是int
    "doubleBalance": "1.0", //真实类型是double
    "bigDecimalHeightInMeters": "2.01", //真实类型是BigDecimal
    "listPermissions": [
      "listPermissions_83e883b91d02",
      "dnsajdnjksadnksjad",
      "this is ele in list"
    ],
    "emptyFavoriteNumbers": [
      "10086", //真实类型是int
      "10000",
      "18897"
    ],
    "localDateTimeBirthDate": 1704437953000, // 时间戳或明文格式 是时间类型的通常处理 都是可以的
    "localDateSignUpDate": 1704384000000,
    "mapGenericInfo": {
      "mapkey": "31232", //真实类型是int
      "mapkey2": "this is str"
    },
    "nullStr": "" //真实类型是String 但是值其实是 null
  }
}

新版后端返回

新的序列化返回结果如下：

按照编程语言的原始类型返回 前端也可以使用原始类型接收 前后端语言的类型系统完全一致 各自进行业务处理的时候可以随心转换

{
    "successful": true,
    "code": 200,
    "message": "请求成功",
    "data": {
        "longId": "100861008610086",
        "strUsername": "strUsername_37bfeda2694b",
        "strCellphone": "strCellphone_d7f281c67ad3",
        "boolActivated": false,
        "intAge": 1,
        "doubleBalance": 1.0,
        "bigDecimalHeightInMeters": 2.01,
        "listPermissions": [
            "listPermissions_83e883b91d02",
            "dnsajdnjksadnksjad",
            "this is ele in list"
        ],
        "emptyFavoriteNumbers": [
            10086,
            10000,
            18897
        ],
        "localDateTimeBirthDate": 1704437953000,
        "localDateSignUpDate": 1704384000000,
        "mapGenericInfo": {
            "mapkey": 31232,
            "mapkey2": "this is str"
        },
        "nullStr": null
    }
}

直观的前后对比如下：

img.png
img.png

注意事项

针对后端统一的包装返回结构： 当中的code字段，这一次我们返回了数字类型，前端需要注意，不要再使用字符串类型

{
    "successful": true,
    "code": 200,  //请注意 我是数字类型
    "message": "请求成功",
    "data": {}
}

实施方式

后端会逐步针对api接口进行整改，前端需要配合相关api的接口实体类型评估影响范围，逐步进行修改，慢慢替换即可 调整方式： 后端通知前端 整改的接口一对一字段类型对比，前端根据实际情况进行修改

Copyright © 2025 aikero