写点什么

公司前端历数后端研发接口 5 宗罪

  • 2020-04-23
  • 本文字数:1807 字

    阅读完需:约 6 分钟

公司前端历数后端研发接口5宗罪

前端和后端应该相亲相爱,当然是建立在“专业”的基础上。


  • 罪状一:没有文档

  • 罪状二:文档不全

  • 罪状三:接口参数没校验

  • 罪状四:没保证接口原子性

  • 罪状五:接口问题不断

  • 今天一位前端开发人员扯起了后端接口的皮,那个兄弟对后端人员提供的接口很大的意见(我是司空见惯),不过他说的也确实有道理,所以结合我的见解,希望提供接口的人员能多加注意。


罪状一:没有文档


例如新的前端人员到了一个新的公司,使用接口时,问这个这个不知道,问那个那个不知道,要文档没文档,这绝对是前端人员最抓狂的事,心里肯定是一千只草泥马奔腾而过。


1.为什么要文档?


文档是当前开发者甚至后面的接盘侠(后面开发者)能够清晰往下做的指引。


即便是简单的东西,但如果不写文档,以后口口相传消耗的工作量会比写文档更多。


好记性不如烂笔头,一段时候后,可能连开发者都忘记接口的用途。


2.文档怎么写?


在线文档。


在线文档易于更新和他人查看,例如可以使用 Swagger 编写接口文档。


PS:Swagger 是一个规范和完整的框架,用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。


本地文档。


本地文档一般用 Word 文档,但是比较不易传播,但能离线查看。


Final~


文档是及其关键的,无论是在线文档还是本地文档,有是关键。虽然写文档是麻烦的事,但对后端人员来说,是利人利己。


罪状二:文档不全


额,就是有了文档,文档里面对接口的描述也可能不全,可能缺每个参数详尽描述(取值范围、类型)、请求方式(GET、POST、PUT、DELETE)、返回数据的所有状态等等。这里面可能最缺就是返回数据的状态!


一般的返回数据结构~


公司的数据接口返回结构是


{s : 0/ 1, //表示此操作的处理状态( status ),一般简单的成功 /不成功,使用 1/0 表示。m : 'xxxx', //表示此操作的提示信息( message ),一般只用来显示操作失败时提示信息。r : [], //表示此操作的返回值( result )count : x //返回的数据条数}
复制代码


这种数据结构看起来没问题,确实也没大问题,问题就是出在 s 这个字段。有许多的接口不仅仅只有两种状态,成功状态只有一种倒是没问题,问题就出在失败状态,失败可能有很多情况,一个简单的 s:0 不能说明失败的原因(即便是有 m 提示信息,但用这个来区分很不靠谱,因为提示可能会变化),我们不总是仅拿 m 做显示用。


升级返回数据结构~


那位同事建议以下方式应答


{s : 0/ 1/ 2/ 3, // 0代表正常,1是参数有误,2是用户不存在,3是用户没权限等等m : 'xxxx', //表示此操作的提示信息( message ),一般只用来显示操作失败时提示信息。r : [], //表示此操作的返回值( result )count : x //返回的数据条数}
复制代码


m、r、count 可以保持不变,但是 s 里面必须包含所有返回状态,代表这个接口所有业务的情况,前端开发人员也就能针对每种情况进行处理。


文档最重要的部分是返回值的状态,我也建议上面的升级返回数据结构,这样就不存在任何不明朗情况。既然写了文档,就把文档写好,写明朗,这也是利人利己地方。


罪状三:接口参数没校验


这个前端人员倒不是很关注,因为本身调接口之前都会先做校验,后端做参数校验只是双重保证。我之前也做过一段时间后端,也犯过没校验参数的错,额,因为后来没有做后端,也就没有去修正。不过还是提醒后端人员,做好参数校验是第一步,不要偷懒了。


统一处理好接口校验,后端好好考虑下。


罪状四:没保证接口原子性


接口的原子性很重要,有时一个接口可能会干几件事,但不一定都能正常完成,这就导致可能存在原子性问题,接口不能准确被调用。


PS:原子性。一个原子事务要么完整执行,要么干脆不执行。这意味着,工作单元中的每项任务都必须正确执行。如果有任一任务执行失败,则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行,事务就会被提交,即对数据所作的修改将会是永久性的。


原子性一定要保证,保证,保证!


罪状五:接口问题不断


前端开发人员调接口时候,可能会存在各自各样的问题,有问题可以理解,程序哪会没有 bug,但不能太离谱啊,后端兄弟们。所以我觉得在给出接口之前自己明确几件事:


1.是否校验参数。


2.是否所有的情况都测试过了,如果可以请写单元测试。


3.是否返回数据准确明朗,响应状态码是否正常。


4.文档是否已经完备。

总结

后端人员多体谅前端人员,在出现问题时,先检查自身,别一上来就跟前端干起来,要是自己的问题就尴尬了。


本文转载自技术琐话公众号。


原文链接:https://mp.weixin.qq.com/s/LZ8bhkOQDjPzPF4t2sccPg


2020-04-23 17:38797

评论

发布
暂无评论
发现更多内容

编程界的新星 — Rust 凭什么被业界青睐(内附学习资源)

Greptime 格睿科技

rust 云原生 时序数据库 分布式时序数据库

浅谈复杂业务系统的架构设计 | 京东云技术团队

京东科技开发者

架构 DDD 架构设计 企业号 4 月 PK 榜 复杂系统

软件测试/测试开发丨面试题之软素质与反问面试官篇(附答案)

测试人

软件测试 自动化测试 测试开发 测试用例 ChatGPT

Matlab实现PCA算法

Shine

三周年连更

3月底JAVA面试太难,吃透这份JAVA架构面试笔记后,成功涨到30K

程序知音

Java java面试 java架构 后端技术 Java面试八股文

从不均匀性角度浅析AB实验 | 京东云技术团队

京东科技开发者

A/B 测试 AB实验 企业号 4 月 PK 榜 不均匀 实验准确度

连ChatGPT都不懂的五一调休,到底怎么来的?

禅道项目管理

程序员 GPT 调休

如何进行带有透明压缩技术的SSD基准测试?

ScaleFlux

扩容 存储技术 压缩数据 固态硬盘 企业数据

开启云上高效开发新时代,华为云开发者日东莞站成功举办

华为云开发者联盟

云计算 华为云 华为云开发者联盟 企业号 4 月 PK 榜

从五一的旅游热潮看,该如何实现数字文旅的转型升级?

加入高科技仿生人

低代码 旅游业 数字赋能

服务百万商家的系统,发布风险如何规避?微盟全链路灰度实践

TakinTalks稳定性社区

Confidential Containers发布0.5.0版本,龙蜥将基于八大特性构建开箱即用的机密容器解决方案

OpenAnolis小助手

开源 云原生 龙蜥社区 机密计算 机密容器

GitHub下载已过百万!阿里这份Java虚拟机源码剖析手册真的绝了

Java JVM 虚拟机

多云管理的六大价值

穿过生命散发芬芳

多云管理 三周年连更

云服务规划技术

阿泽🧸

云服务 三周年连更

5月7日【飞天Club × 云原生技术实践营—飞天免费计划实践专场】开启报名

阿里巴巴云原生

阿里云 云原生 飞天Club

GitHub经典教材!阿里P8的这份SpringBoot精髓到底厉害在哪里?

Java spring 微服务 Spring Boot 框架

通过“群战”实现全民普惠,e签宝带来哪些思考?

ToB行业头条

软件测试/测试开发丨利用ChatGPT自动生成测试用例思维导图

测试人

软件测试 自动化测试 测试开发 测试用例 ChatGPT

好玩的策略游戏:群星Stellaris+DLC

真大的脸盆

Mac mac游戏 科幻策略游戏 游戏推荐 游戏安利

龙蜥社区 4 月度运营大事件回顾

OpenAnolis小助手

开源 运营 龙蜥社区 sig 月度回顾

大型水利投资集团,打造数智财资管理新范式

用友BIP

程序员真的要失业了?新技术潮如何改变我们的职业生涯? | 社区征文

一道圣光

职业成长 ChatGPT 三周年征文

软件测试/测试开发丨Python装饰器常见报错信息、原因和解决方案

测试人

Python 软件测试 自动化测试 装饰器 测试开发

ShareSDK 抖音平台注册指南

MobTech袤博科技

Matlab实现神经网络

袁袁袁袁满

三周年连更

智能公厕设备升级方案@光明源智慧公厕

光明源智慧厕所

智慧城市

SBOM喊话医疗器械网络安全:别慌,我罩你!Part Ⅱ

安势信息

网络安全 SBOM 开源组件 医疗器械 医疗网安

新浪张俊林:大语言模型的涌现能力——现象与解释

NLP资深玩家

公司前端历数后端研发接口5宗罪_文化 & 方法_技术琐话_InfoQ精选文章