整站外包优化公司,金山西安网站建设,网站仿站教程,衡水市网站建设今天与另一位前端开发人员扯起了后端接口的皮#xff08;我也是前端人员#xff09;#xff0c;那个兄弟对后端人员提供的接口很大的意见#xff08;我是司空见惯#xff09;#xff0c;不过他说的也确实有道理#xff0c;所以结合我的见解#xff0c;希望提供接口的人…今天与另一位前端开发人员扯起了后端接口的皮我也是前端人员那个兄弟对后端人员提供的接口很大的意见我是司空见惯不过他说的也确实有道理所以结合我的见解希望提供接口的人员能多加注意。
1.没有文档...
例如新的前端人员到了一个新的公司使用接口时问这个这个不知道问那个那个不知道要文档没文档这绝对是前端人员最抓狂的事心里肯定是一千只草泥马奔腾而过。
为什么要文档
1. 文档是当前开发者甚至后面的接盘侠后面开发者能够清晰往下做的指引。
2. 即便是简单的东西但如果不写文档以后口口相传消耗的工作量会比写文档更多。
3. 好记性不如烂笔头一段时候后可能连开发者都忘记接口的用途。
文档怎么写
1. 在线文档。
在线文档易于更新和他人查看例如可以使用Swagger编写接口文档。
PSSwagger是一个规范和完整的框架用于生成、描述、调用和可视化RESTful风格的Web服务。
2. 本地文档。
本地文档一般用Word文档但是比较不易传播但能离线查看。
Final~
文档是及其关键的无论是在线文档还是本地文档有是关键。虽然写文档是麻烦的事但对后端人员来说是利人利己。
2.文档不全...
额就是有了文档文档里面对接口的描述也可能不全可能缺每个参数详尽描述取值范围、类型、请求方式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里面必须包含所有返回状态代表这个接口所有业务的情况前端开发人员也就能针对每种情况进行处理。
Final~
文档最重要的部分是返回值的状态我也建议上面的升级返回数据结构这样就不存在任何不明朗情况。既然写了文档就把文档写好写明朗这也是利人利己地方。
3.接口参数没校验...
这个前端人员倒不是很关注因为本身调接口之前都会先做校验后端做参数校验只是双重保证。我之前也做过一段时间后端也犯过没校验参数的错额因为后来没有做后端也就没有去修正。不过还是提醒后端人员做好参数校验是第一步不要偷懒了。
Final~
统一处理好接口校验后端好好考虑下。
4.没保证接口原子性...
接口的原子性很重要有时一个接口可能会干几件事但不一定都能正常完成这就导致可能存在原子性问题接口不能准确被调用。
PS原子性。一个原子事务要么完整执行要么干脆不执行。这意味着工作单元中的每项任务都必须正确执行。如果有任一任务执行失败则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行事务就会被提交即对数据所作的修改将会是永久性的。
Final~
原子性一定要保证保证保证
5.接口问题不断...
前端开发人员调接口时候可能会存在各自各样的问题有问题可以理解程序哪会没有bug但不能太离谱啊后端兄弟们。所以我觉得在给出接口之前自己明确几件事
1. 是否校验参数。
2. 是否所有的情况都测试过了如果可以请写单元测试。
3. 是否返回数据准确明朗响应状态码是否正常。
4. 文档是否已经完备。 总结
后端人员多体谅前端人员在出现问题时先检查自身别一上来就跟前端干起来要是自己的问题就尴尬了。 本文为原创文章转载请保留原出处方便溯源如有错误地方谢谢指正。
转载自https://www.cnblogs.com/lovesong/archive/2016/05/26/5533149.html
