Java 接口过滤为null 的字段

文章讨论了在技术从PHP迁移到Golang后,由于接口字段null处理方式改变导致的客户端崩溃问题。解决方案包括让大C在客户端处理或业务方在接口返回时过滤null字段,提出了使用JsonInclude注解或全局配置的策略。作者倾向于大C来处理以避免重复工作和潜在错误。
摘要由CSDN通过智能技术生成

一、问题描述

今天在大C的同学找过来给我们提了个技术需求,让我们将接口里返回的字段全不做一下处理,若字段值为 "null" 的时候就不要返回了,他们APP会崩溃。what ? 我想大家立刻马上会冒出这样一个问题之前不是好好的么这么突然就G了。经过一阵交流才发现是技术加方案变化导致的。

二、问题原因

根本原因就是大C要做技术优化,从之前的php代码迁移到 golang,老的php代码在他们那一层做了一个“字端为null就不返回”的过滤。本次技术优化之后不想做这件事。

老的技术方案实现如下:

新的技术方案实现如下:

三、解决方案

业务架构解决规范性讨论:

解决方案从团队角度来说无非就两种,一个就是他们做,另一个就是我们业务方做。我个人剧的他们做更合适。

  1. 首先技术优化可以做,但是前提不能影响之前的功能性的东西,不然所有的接入放都要进行适配。对接放愿不愿意改是一回,有没有时间是另一回事。

  1. 大C对客户端负责,就一定要保证对客户端的字段的准确性,其实就是三方接口不可信。

  1. 大C来做这件事的话其他业务方都不用做重复性的动作了,这样架构也简洁。

  1. 若是业务放来做,怎么做,做到什么力度也是个问题,不可能在全局做这样的逻辑处理,除非对大C是一个API。但是显然不可能出现这样的架构设计。举个case:一个接口给大C提供了并且做了这个逻辑判断,但是某一天有个同学给大C提供了个新接口没有人提醒他做这样的逻辑处理,测试的时候各个字段都有,结果上线之后由于业务变化某个字段值没有了,客户端不就G了么。

业务放的解决方案:

若是业务方做这件事的话,有两种方式。

1、按照接口返回对象过滤,使用JsonInclude注解,该注解可作用在字段上也可作用在对象上。

# 引的包
import com.fasterxml.jackson.annotation.JsonInclude;

# 具体注解
@JsonInclude(JsonInclude.Include.NON_NULL)

2、按照全局过滤使用配置。

spring:
  jackson:
    default-property-inclusion: non_null

具体采用哪种方式大家视情况而定。大家对于我描述的解决方案的规范性讨论有啥见解,也可以在评论区留言讨论讨论。大家一起进步呀!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值