这种后台接口设计是否合理

不合理，返回数据时就把第五列数据是否满足条件返回，而不是前端拿到数据后在拿着第五列的值去一个一个的请求接口 b 再决定是否展示第三列。
一页 10 条就要请求 10 次，一页 100 条数据就要请求 100 次，关键是哪怕是支持批量也不是很合理，感觉就是了省事而已

就是后端不肯做呗，正常人都知道不合理

先问下后端为啥要这样设计，问问他的考量是什么。有些时候，并不是后端偷懒。很多时候，前端要求后端一次性把数据返回，但是后端也受限于垃圾架构，无可奈何。我碰到过很多需求，都是需要前后端一起协同。建议先问问为什么？

这种肯定是后端要被考核代码量，故意这样写的咯，你们公司肯定是有按代码量来进行绩效考核的，不然后端也不可能这样堆屎山，一个接口的功能，分几个接口实现。建议找你们领导商量一下，取消代码量考核，或者跟后端的人商量一下，看看能不能退一步，如果你一定觉得是后端的人有问题，那就不管了，就按后端提供的接口这样搞就行了，一页一百条、一千条数据，你就循环请求这么多次，一百次、一千次，就是了。

只考虑一个数据表格的话，我一般的设计是分成表头和表格数据两部分，根据实际需求（是否有列显隐控制）决定表头是否需要后端返回。前端不需要考虑数据的含义，只需知道每一列对应一个字段。
像 OP 这种多半是后端拿到的源数据就是分散的（不同数据源甚至系统），不想把数据处理成前端容易使用的结构。
个人认为前端应该是重交互轻逻辑，数据处理尽可能在后端做好，这样相当于在后端一层稳定的和前端交互的接口，之后需求变化后端

点错发出去了
接上文：后端逻辑如何变化对双方交互接口影响很小，前期后端麻烦一点，后面可以节约双方的时间

前端页面只负责展示页面，数据处理逻辑放后端。这么浅显的问题。