浅谈接口问题
根据工作中遇到的问题 想简单阐述下我的见解
最近开发公司一个项目中，发现前后端缺乏沟通造成的时间成本是如此的大，协同开发往往变成了单线开发 即后端接口修改完， 前端调试反馈修改结果， 后端再进行修改，正常的前端工作变成了接口测试的状况。
相信做过几年端开发的都会遇到这样的问题，后端做出的接口方案对于前端来说调用起来非常难受，但又说不上为什么，最近半年偶尔写个全栈的小项目，渐渐的理解了接口设计中的一些利弊，以及如何正确的实践，回想之前，也终于能说出当时自己遇到的痛点。
1. 我的痛点是什么
前后端的对接双方关注甚少，没有任何接口约定规范情况下各自干各自的，导致在产品项目开发过程中，前后端的接口联调对接工作量占比在30%-50%左右，甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。
错误的开发流程
正确的开发流程
接口文档在产品原型期的定义、约束至关重要，投入研发30%的时间都不为过
2. 接口的方案应该交给消费方设计？还是交给生产方设计？
当然是交给消费方，产品的开发，更贴近于一个定制化的设计，消费者自然有权利提出自己的定制意见，生产厂家则需要按照消费者的意愿来交付产品。
API接口一个最可怕的地方在于后端大费周章的把它实现了，但是自己却重来不会使用，于是这极易陷入一种尴尬的境地，因为他更本不知道接口的好坏。好比一个从来不尝自己菜的厨师，甜了咸了都不知道，更别指望他能做出一道佳肴
同样能实现数据功能的接口也是有好坏之分的，坏的接口消费者调用难受，维护者维护难受，间接的影响产品体验。
3. 那话说回来这和接口方案谁设计有什么关系？消费方也不懂代码啊！
当然有关系，因为坏接口产生的原因之一是生产方只站在生产的角度解决问题，并且没有人更比消费者更了解自身的需求，所以有分歧是必然的
举例子：
1. 一个列表页面需要展示用户头像、名字、头像
// 理想中的返回结果:
{
"data": [
{
"name": "小明",
"img": "www.img.com",
"title": "丙",
},
{
"name": "小红",
"img": "www.img.com",
"title": "甲",
}
]
}
// 实际的返回结果
{
"data": [
{
"Name": "小明",
"Img": "www.img.com",
"Title": 3,
"CreateTime": "2019-11-06T06:42:34.373Z",
"CreateTimeT": "string",
"GroupID": 0,
"GroupName": "string",
"Source": 0,
"Note": "string",
"CompanyID": 0,
"QQ": "string",
"EMail": "string",
"Mobile": "string",
"Tel": "string"
},
{
"Name": "小红",
"Img": "www.img.com",
"Title": 5,
"CreateTime": "2019-11-06T06:42:34.373Z",
"CreateTimeT": "string",
"GroupID": 0,
"GroupName": "string",
"Source": 0,
"Note": "string",
"CompanyID": 0,
"QQ": "string",
"EMail": "string",
"Mobile": "string",
"Tel": "string"
}
]
}
很明显看出生产方完全是按照自己的存储结构在设计接口，包括更新一些信息也是如此，极其真实的只提供一些更新数据库表的接口，消费者在其中读数据，写数据。
面对这类底层性质的接口，消费者在集成时需要考虑接口的调用步骤以及理解背后的原理。
如Title为3时界面显示丙，如果后端的底层结构一旦发生更改，接口很有可能也需要发生更改，前端的调用代码也需要随之更改。
2. 还是一个列表 但是需要按照ABCD分栏目展示
// 理想中的返回结果:
{
"data": [
{
"group": "A",
"data": [
{
"name": "阿乐"
}
]
},
{
"group": "D",
"data": [
{
"name": "大红"
},
{
"name": "大绿"
}
]
}
]
}
// 实际的返回结果
{
"data": [
{
"name": "小明",
"group": "X"
},
{
"name": "小胖",
"group": "X"
},
{
"name": "大红",
"group": "D"
},
{
"name": "阿乐",
"group": "A"
}
]
}
又是能看出生产方完全是按照自己的存储结构在设计接口，但这次消费者需要遍历，查找，组合，排序，也只能配合这样的数据结构进行实现，导致的后果是消费者花费多余的时间实现了不需要的代码，这其中消耗的资源最终需要用户买单
3. 一个接口难道不应该只专注一件事情吗？
目前我们已经有创建单个文章的接口，现在需要支持批量创建文章。生产方给出的建议是：不如调单个接口多次？
目前已经有一个接口能够取得文章相关数据，比如内容、评论、作者等等。
现在我们需要增加一个新的页面用于展示用户信息。
生产方给出的建议是：不如使用文章数据接口，里面已经包含了作者信息，这样就不用开发新的接口了
以上的例子看似都是想实现对接口的复用，但实际上起到的是事倍功半的效果,
虽然语义上“创建五篇文章”和“连续五次创建一篇文章”是等效的，但是在实现和操作层面并不是如此。且不说调用五次和调用一次的性能大不相同，批量创建的五篇文章可能存在顺序关系，可能需要事务操作
而使用文章数据接口用来展示用户信息，这并不能算是接口复用，只能算是接口的 hack，这是存在风险的，因为文章数据接口更关注于服务文章数据这个API需求，如果哪天该接口发生改变，是没有义务为展示用户信息API负责，一个接口应该只专注一件事情
接口也是需要不断更新迭代的，恰如前端界面改版一样，旧的淘汰，新的投入使用，这是服务于用户的声音及需求。
最后
售后说白了就是一个企业可持续发展的关键保障和品牌价值的体现，如果生产方希望接口能变得更好，请多听听消费者的反馈。
