2017 年 11 月份阶段性工作心得总结。

概要

预计年底上线的 CRM 系统开发了有一段时间了。从 10 月底开始进行一个第三方呼叫中心系统的所有功能对接（第二个版本估计是要做一个公司自己的呼叫中心系统，有点小期待……）。在对接这个系统期间，遇到了一些坑爹的问题，说实在的作为一个菜鸟，我都看不下去了，在此将各种坑爹总结起来，已共勉。

同一个系列的接口同一个参数不同的命名

• 一开始整理接口的时候，就发现这个问题了，本来想统一处理接口的，但是由于这种问题，只能个接口分别处理。

该系统对外开放的接口有 60 余个，基本涵盖了坐席端、管理员端的所有功能，我们是打算将所有功能对接过来的，那么这么多接口如果能够统一处理，只需要传一个 URL 进去，就能调用不同的接口，想想他有 200 个又何妨，然后，事情并不像我想的那么简单，他们的参数格式并不是同一的，甚至存在同一个参数不同的接口命名不同的情况

例如：

interface a;需要三个参数：用户名、密码、热线号码。
interface b 同样需要这三个参数。

在请求a接口的时候，接收的参数是： userName、pwd、hotLine
但是在请求b接口的时候，接收的参数竟然是：account、password、hotLine

这几个字段取值都是同样的……

这就比较尴尬了，所以我最起码要有两个方法去组装这些公用的参数。

返回值类型不统一

• 如同参数不统一一样，返回值类型不统一也是一个蛋疼的问题。

这个直接上图大家看：

1.首先这一个，是一个删除接口，上面的是删除失败的返回值，下面的是删除成功返回值。

一般删除这种都会返回一个状态码，来标识成功与否的，最起码返回的 json 格式应该都是一样的吧,起码你来个下面这种还能接受。

{"result":"success","msg":"删除成功"}
{"result":"error","msg":"该技能Id不存在"}

2.实际接口返回信息与文档说明不一样。

接口文档说明：

实际接口返回：

这个坑爹的时候乍一看和接口说明的是一样的，但是我转 json 解析竟然报错了，仔细一看，你妹的 ，竟然有一个是这么特殊的。

接口文档说明：

实际接口返回：

还是上面那种，不光成功和失败返回 不一样，还和文档说明也是不一样的……

总结

除了例子说的，还有其他一大堆类似的问题，60 个接口，一个多星期的对接，没对接一个接口，都像吃了一只苍蝇一样。原本写好的代码只能改变去妥协（因为他们的接口已经有很多人在调用了，他们去改的话，所有调用的人都要改一遍。。。）

看到了这些接口，想想我们自己写的代码，还算是规范许多的，不过这种问题还是要多注意才好。