前端对接这样的 API ，各位老哥有什么建议吗

[doommm]

前端对接这样的 API，各位老哥有什么建议吗

先说一下项目背景

互联网公司，做自己的产品，全新的统计项目。3 人团队，1 产品 + 1 后端 + 1 前端。

项目负责人(产品)是从银行出来的，和后端一起设计、维护数据库，制定了前后端 API。

上个月就 API 字段命名方式我提过一个问题( https://www.v2ex.com/t/514030)

后续和负责人沟通的结果是：API 和字段名没有改变的可能，没有、也不会提供什么字段表，不好做就自己想办法。

当时大家建议去做 mapping，因为各种原因，目前我只把这些 code 全部变量化，加上 JSDoc，并且所有跟这些 code 相关的代码都单独用TypeScript来写。

目前页面已经写完了，用的 Vue + echarts，数据目前都是我本地 Mock 的，因为 API 给的晚，Mock 的格式没有和实际完全对应。

API 示例

// request params
// 请求 A 表这些字段，post to api/a
{
  "date_start": "2019-1-1",
  "date_end": "2019-1-3",
  "id": "v2ex",
  "cols": "A0001,A0002,A0003,A0004..." 
}
// B 表，post to api/b
{
  "date_start": "2019-1-1",
  "date_end": "2019-1-3",
  "id": "v2ex",
  "cols": "A0001,A0002,B0001,B0002..." 
  // ...
}
// ...

// 前端请求哪些字段，后端就只返回这些字段的数据
// 部分字段通用
// 返回数据格式区分宽表、窄表

// 宽表返回格式
{
  "A0001": "2019-1-1", // date，通用
  "A0002": "v2ex", // id，通用
  "A0003": "1",
  "A0004": "1",
  // ...
}

// 窄表返回格式
{
  "A0001": "2019-1-1",
  "A0002": "v2ex",
  "INDEXID": "F0001"
  "INDEXV": "1"
},
{
  "A0001": "2019-1-1",
  "A0002": "v2ex",
  "INDEXID": "F0002"
  "INDEXV": "1"
},
// ...

• A0001, A0002 这些都是实际的字段名，也是数据库的列名，有一张 Excel 的对照表可以查字段的含义。前端需要哪些列的值，就把相应列的 code 作为请求的参数传给后台。

• 后台返回格式不一致(宽表、窄表两套格式)。

• 不同的首字母表示不同的表，对应的字段需要 post 到不同的 API。比如 AXXXX，BXXXX 要分别给到api/a, api/b两个接口。

• 一项业务存在使用多张表的数据的情况，前端需要自己来做数据聚合。

• 根据业务需要，前端要对部分返回结果做过滤 /分类 /计算。

• 同一项指标的不同选项(比如留存，有 3 日、7 日、14 日等选项可选)会对应不同的 code，前端需要区分发送。目前我用表驱动法维护了很多这类的 mapping。

考虑的问题

• 业务逻辑的维护

目前我针对每一项具体业务写了 Adapter ，用来管理要发送的数据列，以及返回数据的转换处理工作 。

感觉项目中用的最多的就是 Array.map, Array.reduce 这两个方法。。UI 的文本、各种选项下对应的请求字段、各种图表数据都跟那些 code 做了对应。很怕以后维护的时候看不懂。

• Ajax 请求数量

目前各个业务模块的请求是单独发送的(一个页面多个模块)，一次刷新 devtool 里面各种 abcdef 的请求，如果存在跨表的业务(Promise.all 等待)就有更多。等浏览器排队走完。

目前后台数据还不完善，很多返回值都是 null，速度还无法评估。

请问前端目前这样处理有没有什么问题？听说过 GraphQL， 不知道是不是可以解决这类问题？不过估计也没有用的机会。

---

还想问问各位老哥，前端对接这样的接口，有没有什么好的做法？有没有什么坑是需要注意的？

另外，因为以前只做过后端给大接口(聚合了目标业务需要的所有数据)的项目，想问问这样的接口算不算 RESTful ？ 后端 API 这样设计，是不是后续只要负责往数据库里面填数据就可以了？

---

试用期还有一个月，做的好心累，感觉自己好菜

[preach]

楼主在北京的话考虑我公司吧 私我简历

[qinrui]

说到前后端 api，我又想到了建行网站。建行 web 有个页面，展示了数据 A，而数据 A 是个汇总值，汇总成这个值的明细数据并不需要在 web 上展示。

但大方的建行，将全部明细数据都通过 api 吐给了前端，前端通过 js 汇总再显示出来。

真真的体会了前后端“分离”

[kltt22]

我公司前端和客户端是块宝，后端写接口都要考虑前端好不好实现。不好实现的，后段就再加工下。感觉后端处理数据还是方便些。

[MonoLogueChi]

我想到了，我给别人做后端，有个只有几十行数据的表，我都想不管他怎么查，我直接把整个表返回给他，让他自己在前端去做处理。后来想想算了，没敢跟他说，怕被打死，老老实实的去做正常 API 了

[duan602728596]

不能跨表查询，那还要后端和数据库干毛线？我这个半吊子都能对付写个查询把数据查出来

[Akiyu]

@kltt22
主要是后端经常干这些事情, 比较熟练

[shew2356]

那前端还不如自己全部搞定得了

[MonoLogueChi]

@kltt22 我也感觉后端处理和加工数据比较简单，但是为了性能时候，这些应该是前端做的

[MrUser]

能力太低，看不透，问下，如果那个“ Excel ”泄漏了，你们这不是白折腾吗
加密有很多方法和适用场景，这样写莫不是要把所有加密方法方式都用上？
这个规范加上后端那样的接口，如果他们不改，我是不会呆下去了

[reus]

垃圾后端，这都能忍，屎都能吃了。

[chniccs]

这？是让你做全栈？后端=数据库连接工具？

[jrtzxh020]

那后端所有数据都 select * from xx_table 得了。然后给前端自己处理，哈哈

[drydiy]

GraphQL 是要前后端一起配合的。
一般情况下，人少的团队最好配合的，没什么历史包袱，分歧也少。
你们 3 人团队搞成这样，不觉得恶心？？

[lihongjie0209]

瞎搞

[ytmsdy]

假如后端走了，新来接手的后端会一脸懵吧。

[90d0n]

这后端写的真轻松啊, 找个模板一键生成接口就行了...
同 11 楼, 这后端完全就是个数据库连接工具... 还是只查单表的

[julio867]

听说银行的系统的命名方式都是类似的~~之前做过中小企业的 C/S 管理软件，字段命名也是类似，不能说不好，只能说看团队和项目情况~~
个人一直认为的是，API 接口返回的数据，应该仅仅是调用者需要的，而不是把所有数据都扔给调用者，否则后端就真的是“数据库连接工具”了（当然，这个可能对于某些项目不一定是合适的）~~

[yikyo]

相信我，换个工作吧，别忍着了。

[xpol]

GraphQL 挺好的，可以研究一下。

[doommm]

@drydiy

一开始肯定不能接受，所以才有上个月发的那帖，当时只知道大概的数据格式，还没有 API。

当时有老哥说见过这种格式，这样的字段命名方式是有原因的，我就尝试去接受，想法子来做了。

然后越做越觉得难，想说是不是哪里做的不对，就又来发帖请教了。

[doommm]

@preach 谢谢老哥。人在厦门，暂时不考虑北京。再次感谢。

[doommm]

@qinrui
产品还就是从建行出来的。。这个项目里面也有类似的需求需要这样实现。。

[dany813]

这个设计真牛逼，要是我立马就开怼

[183shl]

我见过查询用户信息把 passwd 也返回的

[daimen]

BQID。。。 哈哈哈哈哈哈哈哈哈

[yepinf]

@preach 哈哈哈

这么干脆~ 有没有上海的

[preach]

@yepinf 救人要緊

[tosmq009]

如果考虑到字段加密来说，我觉得可以考虑 你们的设计，如果直接放到物理数据库，我只能说。。。。
这水平太差了，还活在 10 多年前的 世界，可维护性，可读性，都是垃圾

个人建议，找技术老大提问题，如果大家都不是好好做事的心态的话，赶紧找下家，不然工作水平提不上去，心态还各种纠结。


数据库设计，最近很火的是，领域驱动设计，或者最简单的

能准确表达。

[vivachencs]

上家公司后端也是这么干的, 数据统计全是我前端在做, 完事还要说: "你看我接口写得多灵活, 你想要什么数据都可以自由组合, 性能还这么好", 然后我现在跑路整一年了

[519718366]

我们这边前后分离奉行的原则是：能后端处理的，就不交给前端。

比如前端的某个状态要根据 2，3 个属性综合判断，那后端基本就把这个状态计算好了返回。

前端就塞塞值，换换文案，多搞搞交互样式代码。

你这种字段设计绝对不是个例，我一个做过社保项目的同学也是你这样的，他说后端数据库是专门有一张字典表的。
这个表说明了 A00001 表示什么意思，一般值什么的~~所以你前端也搞个字典？

[Ritr]

后端返回的数据不一定符合前端的需求，当前端页面展示变更的时候，后端也不一定跟着变更。
我的建议是使用一个中台系统来整合、梳理这些数据。
如果没有时间和精力做这个事情，可以考虑在前端 /后端加个适配器处理数据，保证数据输出的格式符合你的需求
"3 人团队，1 产品 + 1 后端 + 1 前端" oh ...shit，还是随便搞搞吧

[kela]

@qinrui 我以为要两开花

[doommm]

@dany813 试用期，怕是怼不动

[mynameisz]

劝楼主，苦海无涯，回头是岸！

[shyangs]

壮哉大前端, JavaScript 必将统一世界

[atonku]

我也像写这样的接口，但是我怕会被领导打死。这尼玛写的是个屁哦

[bojackhorseman]

@MonoLogueChi #4 233

[SakuraKuma]

自己架中间层，写 mapping，转换回自己要的格式。就不用暴露字段前端又好写点了。

[ChenFanlin]

..我记得之前在 v2?还是 nga?看到过有个帖子也是这样的命名...同一家公司吗...

[yzkcy]

后端把表里所有数据全传到前端，让前端自己处理，会产生很严重的安全问题的。

比如查询 XX(前端只需要 XX 的某个值)，后端却把 XX 的所有数据(包括敏感信息)全返回了。

[rasck]

怎么不直接传 sql 语句 23333

[rasck]

@ChenFanlin 我也以为碰见同一家公司了，仔细看下楼主说了上个月发过帖子问过了

[jinhan13789991]

让后端给你数据库地址和密码，自己直连数据库。

[ChenFanlin]

@rasck #42 多谢, 眼瞎了....,那确实也算是同一家公司了

[reself]

不给映射表做个鸡巴，这后端已经不是懒了，完全没有团队意识

[stzz]

这种设计要后端干嘛,和直接传 SQL 语句有啥区别

[yamamotoahua]

@chniccs 前端=设计稿具现化工具？ 233

[auroraccc]

按照你们这个后端和项目负责人的性格，不要想 graphql 了，这个需要后端配合的

[doommm]

@ChenFanlin 同一家公司

[doommm]

@tosmq009

公司将近 100 人，按产品组分的。这个项目组是单独一个小组，产品直接对老板负责，前端没有技术老大

[lolizeppelin]

让不让看后端代码？ 让看 看完再喷呗

[noe132]

比我之前待的公司 api 接口从 function001 到 funtion152 还是强一点。。。
传个二维数组，用逗号分隔后再用分号分隔连接成字符串传给后端
后端再存储过程里再去解析出来。。。

[doommm]

@reself …所以是要赶紧跑路吗

[qinrui]

@doommm 而且建行这个页面，api 吐出的 json 格式还不符合规范，真的烂

[947211232]

这么有诗意的规范实在令人倍感无力。

[dapang1221]

感觉吐槽这种字段名的帖子已经挺多了，等保要求里好像的确是有这个加密要求，规定如此……

[kingcos]

我比较奇怪的一点是，微服务微服务，应该是针对后端的逻辑，前端需要什么东西就不能组装一下吗…难道后端微服务，前端就要一次性调四五个接口才能拿到所有需要的数据，这样割裂的，是微服务的锅？

[Lindp]

我相信大部分公司应该都是前端是大爷，后端应该准备好所有数据给前端服务，而且还要是前端最简单的实现方式，毕竟数据还是后端处理起来方便嘛

[Gakho]

@kingcos 微服务 API 网关了解一下

[doommm]

所以真的没有什么建议吗

[doommm]

@Ritr 随便搞搞是说先把项目搞出来，其它什么的暂时就别考虑了么

[Ritr]

@doommm 先跑起来吧，看着也不是大项目

[doommm]

@Ritr 跑起来了，现在产品要我去翻旧版项目（ PHP, jQuery ），把新旧两套数据库字段的对照关系整理给他，他好做迁移，这要怎么搞？

[Ritr]

@doommm 这后端也太懒了吧，我晕，你让自己整理对照关系呗

[doommm]

@Ritr 职级比我高怎么解呢，我是真的在考虑趁还在试用期赶紧离职。。。

[Ritr]

@doommm 那就等过完年跑路吧

[serge001]

@doommm 想请教下最后怎么解决的呢?我的想法是统一在请求层 map 处理一下