一个接口引发的前后端处理数据标准的思考

[Irisxx]

楼主本身 技术栈是移动端(ios + flutter)，前端在学（新手） 以下是一个实际的应用场景举例: 一个普通的列表显示接口 A:

其中 styles 和 types 分别需要另外调用 接口 B 和 接口 C ，返回的数据格式类似如下: 需要匹配用第一个接口里的 styles 的数字去匹配第二个数组里的 value,一旦匹配上把当前的 label 值塞到第一个接口的自定义字段的返回值里去，最后显示

v 友的第一个观点大概是上来先把接口 2 所有类型的数据拉取下来，然后本地维护这个数组去做匹配，这个方案呢也是我一开始想到的，但是呢后台不支持所有类型数据下发，第二呢后端前面提过这个 value 和 label 的绑定是动态的，我猜大概是为了实时性的缘故吧

目前状态呢是我这边已经处理完了这部分数据，但是安卓呢不愿意处理，后端也不愿意处理 我这边就是最常规的做法，同时请求 x 个接口，然后等待都返回后 去匹配值，用哈希表稍微优化了一下匹配时间复杂度，但我觉得这对一个最基础的列表展示是不是过于繁琐了。如果风格是 100 个，返回的是 80,90,99 呢。

鉴于 V2 大佬多，想问问像这种情况有没有标准，到底应该哪边处理比较好，后端处理的话当然也要做匹配。还有个疑问就是这部分数据上传的时候难道不是上传字符串的吗，会有什么场景需要专门把这些风格还专门做成 1,2,3 ，4.在我看来这不是多此一举吗。

[Jed2020]

论接口文档的必要性

[iidear2015]

目前没见过统一的标准。一般大家会根据一些不成文的原则来协商

1. C 端应用，一般用户体验优先。在前端处理的话，会多一次请求，导致用户等待时间变长，所以后端处理。
2. M 端应用，一般效率优先。看前后端开发压力，和后续维护成本。

具体到你这个问题，后端处理更好。iOS 和 android 需要重复开发，逻辑收敛到后端，维护成本更低， 用户体验也更好。

上面只是说放在哪一"端"合适，实际由前端人员还是后端人员来做就需要"讨论"了。大厂里会存在前端开发人员写后端服务，可以搜一下 BFF 层。

[Irisxx]

@iidear2015 了解了下，确实 BFF 适用于这种场景，只是我的技术栈中没有 JAVA ，前端做 BFF 避不开多线程拉请求 。

[dayeye2006199]

问就是 graphQL

[gerefoxing]

这种字典值显示都是后端处理，后期修改的话后端直接在数据库改下同步到缓存中就行了