跳到主要内容

做接口开发最烦的，不是 JSON 深，而是它打断你思考业务

· 阅读需 4 分钟

做接口对接久了，我越来越反感一种代码：

明明只是取几个字段，却写成这样：

Object dataObj = response.get("data");
if (dataObj instanceof Map) {
    Map<String, Object> data = (Map<String, Object>) dataObj;

    Object orderObj = data.get("order");
    if (orderObj instanceof Map) {
        Map<String, Object> order = (Map<String, Object>) orderObj;

        Object amountObj = order.get("amount");
        if (amountObj instanceof Integer) {
            Integer amount = (Integer) amountObj;
        }
    }
}

它当然没错。

但它有一个很严重的问题：

它会不断打断你对业务本身的思考。

更麻烦的是，这种打断不是只发生在第一次开发时。

很多接口代码第一次写出来，也许只是显得啰嗦一点。真正难受的是，过几天接口结构一变，你还得回头钻进那一大段旧代码里，重新确认每一层判空、每一个中间变量、每一次强转，到底是不是还成立。

这是一种重复、枯燥，而且很容易出错的劳动。

真正复杂的，从来不是取值。

接口对接真正该思考的是：

  • 状态怎么流转
  • 幂等怎么保证
  • 数据是否合法
  • 异常怎么补偿

这些才是业务复杂度。

但现实里，我们经常把大量精力浪费在机械解析上：

  • 这一层是不是 null？
  • 这里是不是还要 instanceof？
  • 多嵌一层会不会炸？
  • 这段判空有没有漏？

最后变成：

业务并不复杂，代码却把它写复杂了。

问题不在 JSON，而在表达方式​

很多接口字段变动，其实只是结构调整。

某个字段往里挪一层，某个对象换个名字，或者外面又包了一层节点，本质上都不算业务重写。

比如：

今天：

data.order.amount

明天：

data.payment.amount.value

按理说，这种改动应该只是：

改一个路径。

但如果你的代码是层层展开的：

你往往得回去：

  • 重读那一大段旧代码
  • 重新确认中间变量和判空
  • 担心漏掉某个强转或某个分支
  • 再做一轮回归测试

本来只是结构小改，最后却变成一次重复而危险的维护劳动。

一行路径访问，让变更点一眼可见​

后来我把这类取值尽量统一成了路径式访问。

目的不是把代码写得像脚本语言，而是把“这个字段到底从哪里取”写清楚。

以 JSONMap 为例，可以直接这样写：

JSONMap response = new JSONMap(body);

Integer amount = response.getInt("data.order.amount");
String orderId = response.getStr("data.order.orderId");
String openid = response.getStr("data.user.openid");

中间任何节点是 null，或者路径不存在，这些方法就直接返回 null。调用方再按业务需要决定怎么处理。

字段结构变了？

改这里：

response.getInt("data.payment.amount.value")

结束。

不用补判空，不用新增中间变量，也不用重新梳理整段解析逻辑。

你真正需要关注的，变成了两件事：

  • 这个字段现在应该从哪条路径取
  • 这次结构变化会不会影响后面的业务判断

当取值表达足够清楚时，这两件事是一眼就能看到的。

这不只是“代码更短”​

真正的价值是：

你的注意力终于可以留给业务。

看到：

response.getInt("data.order.amount")

你的大脑处理的是：

这个字段从哪里取

而不是：

判断 data → 判断 order → 判断类型 → 再取 amount

接口结构变了，你顺着路径就知道该改哪里；业务规则变了，你也能马上把注意力切回业务本身。

这种清晰感，在要维护很多接口、很多字段的时候，会被不断放大。

最后​

很多接口代码看起来复杂，不是因为业务复杂。

而是因为：

我们把“取字段”写成了一场结构解析工程。

真正耗人的，不是第一次多写了几十行。

而是接口一变，你就得回去重读那一大段旧代码，重新走一遍判空、强转、中间变量和上下文。

这是一种重复、危险，而且几乎不创造新价值的劳动。

更好的状态是：字段从哪里取，一眼能看明白；结构哪里变了，一眼能定位；业务哪里要改，注意力能立刻回到业务本身。

这才是做编程工作最宝贵的东西：

连续思考的心流。

附：文中示例所用工具