写点什么

公司前端历数后端研发接口 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:38866

评论

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

🎅Less快速学习(下)🎅

空城机

CSS 大前端 less 11月日更

给面试官上一课:HTTPS是先进行TCP三次握手,再进行TLS四次握手

热爱java的分享家

Java 架构 程序人生 编程语言 经验分享

【死磕Java并发】-----Java内存模型之总结

chenssy

11月日更 死磕 Java 死磕 Java 并发

Go 语言学习查缺补漏ing Day1

Regan Yue

Go 语言 11月日更

金链银链不如区块链 如何利用区块链技术探索“太空世界”?

CECBC

太顶了!华为高工用一份423页的网络协议笔记把计算机网络讲清了

热爱java的分享家

Java 架构 面试 编程语言 网络协议

共建全栈国产化解决方案 | OceanBase持续与合作伙伴推进测试互认

OceanBase 数据库

数据库 分布式 双十一 oceanbase

【Three.js】随着元宇宙开启WEB3D之路

devpoint

JavaScript WebGL 3D three.js 11月日更

惨遭GitHub直接封杀的阿里P8手敲出来这份565页凤凰架构分布式手册,有何神奇之处

热爱java的分享家

Java 面试 程序人生 编程语言 凤凰架构

黑客常备20个工具,你知道几个?

喀拉峻

如何巧妙使用Camtasia制作PPT讲解视频?

淋雨

Camtasia

区块链技术如何在涉诉信访中显身手

CECBC

第三代分布式数据库来了,真香!

OceanBase 数据库

数据库 开源 分布式 oceanbase

千万级学生管理系统的考试试卷存储方案设计

Beyond Ryan

蚁剑的分析和利用

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

到底什么才是真正的区块链游戏

CECBC

clickhouse sql之Array函数

WindFlying

度小满启动“小微加油站”,让低息服务可持续

脑极体

深入浅出,一文吃透mysql索引

微客鸟窝

MySQL 11月日更

🍃【Spring专题】「实战系列」重新回顾一下异常重试框架Spring Retry的功能指南

码界西柚

spring 11月日更 Spring retry Guava retry

阿里大规模业务混部下的全链路资源隔离技术演进

阿里巴巴云原生

阿里云 云原生 资源隔离 ACK 混部

“敏捷版”全链路压测

阿里巴巴云原生

阿里云 云原生 全链路压测 PTS

MySQL事务的实现原理之Undo Log的分析

卢卡多多

Undo Log 11月日更

.NET6新东西--Lambda优化

喵叔

11月日更

家庭太阳能发电,何时能告别“两极分化”?

脑极体

FFmpeg[5] - 将视频文件转码成MP4格式(FFmpeg转封装2)

liuzhen007

11月日更

两个排序数组的中位数,“最”有技术含量的解法!

老表

Python 算法 LeetCode 11月日更

运维体系建设思考-稳定性篇

ning

运维 云原生 监控 稳定性

推动数字化转型,OceanBase 助力保险企业创造新价值

OceanBase 数据库

数据库 开源 技术宅 oceanbase 分布式,

双11“剁手”后,你的包裹收到了吗?

OceanBase 数据库

数据库 开源 分布式 oceanbase

我理解的CPI和PPI

石云升

学习笔记 11月日更

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