java如何动态的处理接口的返回数据
烂笔头 人气:00、需求说明
业务场景:服务A对接了服务B,服务C等服务的一些接口,然后由服务A统一暴露接口给到外部用户使用。
需求是:
- 服务A可以动态的接入服务B/C的接口,对外暴露并无需重启(不在本文的讨论)
- 对接的服务B/C的接口部分字段需要过滤掉,不透出给外部用户(如数据库的自增ID等敏感信息)。
1、 思路方案
基本思路:在服务A里对各个服务接口返回的数据进行拦截并二次加工后再返回给前端。
拦截:比较简单,可以在服务A对其他服务接口请求的返回之后进行业务操作,也可以统一放到切面里用 @After 注解进行操作。从 demo 的快速演示考虑,这里选择直接在请求的返回体直接进行业务操作。
二次加工:服务A对返回body的部分字段过滤掉,不返回给前端。二次加工的方法有很多种,比如:
a. 用一个 map 去接收 body,然后对这个 body map 进行遍历,和服务A里的 map 进行比较, 将服务A map 里需要的 key-value,从 body map 里遍历取出,put 到一个新的 map,最后返回这个新的 map 给前端。
b. 用 string 去接收 body,接收到的body是一个 json 字符串,然后将 json 字符串转成特定的对象(这个对象是返回给前端的),这样对象里没有定义的字段在 json 字符串转对象的过程中就会被舍弃。
方案a有几个缺陷:
- 首先,要求其他服务接口的返回必须是一个 json 类型(可用 map 接收),如果是一个 json数组([{},{}])的话, 就无法用map接收,这样会导致对接入服务的接口数据结构有限制,不ok;
- 其次,map 数据类型可能会很复杂,由于不确定 map 里的 value的数据结构是 string,list 还是 map 等,就需要用 instanceof 对所有的数据结构进行遍历判断再比较赋值,很复杂,计算效率也不高。
- 没有可利用的轮子,类似将对象A赋值给对象B的属性拷贝(BeanUtils.copyProperties()),可以将mapA的 key-value 赋值给mapB
# mapA { "a": "a", "b": "b", "c": "c" } # mapB { "a": null, "b": null, }
相反,方案b有一个很大的优势:可以利用现成的序列化和反序列化工具(如Gson)来实现我们的需求。先放一个反序列化的工具,后面会用到:
/** * Json字符串转为指定的对象 * @param ret json字符串 * @param clazz 指定对象的类 * @return T 指定的对象 */ public class JsonUtil { public static <T> T jsonStr2Obj(String ret, Class<T> clazz) { Gson gson = new Gson(); return gson.fromJson(ret, (Type) clazz); } }
但是说到这里,解决的只是对接口返回body的修改,没有体现出标题的“动态”二字。那么如何可以动态的对返回的body数据进行过滤处理呢?用 groovy 动态加载类。
2 、 具体实施
- 获取接口的返回(以string类型):
ResponseEntity<String> exchange = restTemplate.getForEntity($url, String.class); String body = exchange.getBody();
- 通过groovy获取动态编译类
String clazzInString = getFromRedis($key) // 从redis获取字符串类型的java class Object obj = DynamicClassCompilerUtil.run(clazzInString)
public class DynamicClassCompilerUtil { public static Object run(String cls) { Class<?> clazz = new GroovyClassLoader().parseClass(cls); try { return clazz.newInstance(); } catch (Exception e) { log.error("parse groovy class failed: {}", e); return null; } } }
- 将 body 反序列化
Object ret = JsonUtil.jsonStr2Obj(body, o.getClass())
该 ret 对象即为过滤后的对象,可以加工后返回给前端。
至此,“对接的服务B/C的接口部分字段需要过滤掉,不透出给外部用户(如数据库的自增ID等敏感信息)” 需求实现了。
至于 “服务A可以动态的接入服务B/C的接口,对外暴露并无需重启” 需求,有时间的话,将会另起一篇来讲。
加载全部内容