V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2185 天前的主题，其中的信息可能已经有所发展或是发生改变。

前端对接这样的 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 这样设计，是不是后续只要负责往数据库里面填数据就可以了？

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

67 条回复 • 2019-06-09 23:16:57 +08:00

preach

2019-01-04 01:45:04 +08:00

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

qinrui

2019-01-04 03:08:39 +08:00 via iPhone

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

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

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

kltt22

2019-01-04 07:24:46 +08:00 via Android

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

MonoLogueChi

2019-01-04 07:55:57 +08:00 via Android

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

duan602728596

2019-01-04 08:04:06 +08:00 via iPhone

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

Akiyu

2019-01-04 08:09:37 +08:00

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

shew2356

2019-01-04 08:13:37 +08:00 via iPhone

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

MonoLogueChi

2019-01-04 08:14:59 +08:00 via Android

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

MrUser

2019-01-04 08:18:21 +08:00

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

reus

2019-01-04 08:49:00 +08:00

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

chniccs

2019-01-04 08:54:59 +08:00

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

jrtzxh020

2019-01-04 09:00:36 +08:00

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

drydiy

2019-01-04 09:01:52 +08:00

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

lihongjie0209

2019-01-04 09:08:07 +08:00

瞎搞

ytmsdy

2019-01-04 09:12:14 +08:00

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

90d0n

2019-01-04 09:12:38 +08:00

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

julio867

2019-01-04 09:14:19 +08:00

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

yikyo

2019-01-04 09:14:41 +08:00

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

xpol

2019-01-04 09:14:44 +08:00

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

doommm

2019-01-04 09:46:10 +08:00

@drydiy

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

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

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

doommm

2019-01-04 09:53:20 +08:00

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

doommm

2019-01-04 09:54:59 +08:00

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

dany813

2019-01-04 10:00:40 +08:00

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

183shl

2019-01-04 10:26:17 +08:00 via Android

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

daimen

2019-01-04 10:42:00 +08:00

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

yepinf

2019-01-04 10:49:56 +08:00

@preach 哈哈哈

这么干脆~ 有没有上海的

preach

2019-01-04 10:52:07 +08:00

@yepinf 救人要緊

tosmq009

2019-01-04 11:02:08 +08:00

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

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

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

能准确表达。

vivachencs

2019-01-04 11:05:50 +08:00

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

519718366

2019-01-04 11:21:58 +08:00

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

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

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

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

Ritr

2019-01-04 11:38:02 +08:00

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

kela

2019-01-04 12:12:22 +08:00 via Android

@qinrui 我以为要两开花

doommm

2019-01-04 12:55:52 +08:00

@dany813 试用期，怕是怼不动

mynameisz

2019-01-04 13:18:37 +08:00 via iPhone

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

shyangs

2019-01-04 13:25:12 +08:00

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

atonku

2019-01-04 13:28:43 +08:00

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

bojackhorseman

2019-01-04 14:08:11 +08:00

@MonoLogueChi #4 233

SakuraKuma

2019-01-04 14:12:00 +08:00

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

ChenFanlin

2019-01-04 14:23:26 +08:00

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

yzkcy

2019-01-04 14:57:33 +08:00

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

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

rasck

2019-01-04 15:12:41 +08:00

怎么不直接传 sql 语句 23333

rasck

2019-01-04 15:13:34 +08:00

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

jinhan13789991

2019-01-04 15:19:57 +08:00

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

ChenFanlin

2019-01-04 15:20:20 +08:00

@rasck #42 多谢,

眼瞎了....,那确实也算是同一家公司了

reself

2019-01-04 15:20:54 +08:00 via Android

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

stzz

2019-01-04 15:32:14 +08:00

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

yamamotoahua

2019-01-04 15:36:22 +08:00

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

auroraccc

2019-01-04 15:39:42 +08:00

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

doommm

2019-01-04 17:05:15 +08:00

@ChenFanlin 同一家公司

doommm

2019-01-04 17:07:52 +08:00

@tosmq009

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

lolizeppelin

2019-01-04 17:11:14 +08:00

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

noe132

2019-01-04 17:56:27 +08:00

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

doommm

2019-01-04 20:14:12 +08:00 via Android

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

qinrui

2019-01-04 22:56:03 +08:00 via iPhone

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

947211232

2019-01-05 00:16:25 +08:00

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

dapang1221

2019-01-05 00:22:54 +08:00

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

kingcos

2019-01-05 00:28:21 +08:00 via iPhone

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

Lindp

2019-01-05 10:40:14 +08:00

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

Gakho

2019-01-05 10:42:00 +08:00

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

doommm

2019-01-06 00:08:31 +08:00

所以真的没有什么建议吗

doommm

2019-01-07 00:00:43 +08:00

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

Ritr

2019-01-07 10:18:10 +08:00

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

doommm

2019-01-14 21:07:37 +08:00

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

Ritr

2019-01-15 09:47:36 +08:00

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

doommm

2019-01-15 12:51:17 +08:00

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

Ritr

2019-01-15 13:13:26 +08:00

@doommm 那就等过完年跑路吧

serge001

2019-06-09 23:16:57 +08:00

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

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

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

API 示例

考虑的问题