产品经理不需要深入了解各接口的实现原理,毕竟术业有专攻,但了解在什么样的场合应该使用什么样的接口还是有必要的,可以更方便地对外提供数据服务。
在刚成为产品经理的时候,“这个产品经理什么都不知道。 这个需求那么多的界面,开发也很辛苦,却要排这么多的开发时间,有什么问题我也不负责! 经常听到这样的开发吐槽。
每次听到这样的吐槽,总是一副冷漠的表情。 ——是什么接口? 什么情况? 我又做了什么?
之后,在自己开发之后,我知道了在系统层面,不仅有可以看到的页面功能,还有很多隐藏在页面功能下面的接口。
这篇文章简单总结。 我眼中的界面是什么样的? 然后,为什么要学习API接口的知识?
什么是接口?
API接口: APP编程接口(API )是经由API接口实现计算机软件之间相互通信的一系列例如,假设我开了一家银行,开放了存款/取款服务。 如果要用普通存款人手上的支票取存款,首先必须找到对应的【位置】,也就是正确的银行,正确的柜台。
只要按照银行规定的【支票格式】填写,就可以用这张“支票”取钱。
另外,柜台有限,来取钱的客人可能也很多。 因此,客户需要【按号码排队】,然后依次进行取款服务。 为了考虑安全和服务质量,银行柜台需要【反馈机制】。 如果您的支票填错了,或者支票已经过期,您必须告诉客户重新填写。
【位置】:系统对外发布的API地址。 包含IP、端口、API名称等信息。
【支票格式】:该接口的数据传输规格。 例如,SKU只支持9位长的字符串数据,库存只支持16位长的数字。 如果传输格式错误,【反馈机制】将启动。
【编号队列】:接口的“消息队列”。 消息队列的主要特征是异步处理,可以缩短请求响应的时间,消除耦合。 请想象一下。 如果取钱的人不是【按号码排队】,而是一下子涌进柜台,柜台能提供正常的服务吗?
【反馈机制】:接口内的返回参数,为了保证对方能够正常获取所有数据,要防止数据因数据异常等而丢失。 发现异常时,有必要通知对方发生了什么异常,为什么不能取得该数据,对方根据其反馈进行适当的调整、重新发出请求、放弃该数据。
注:开发者口中的“协作”,简单来说就是在两个系统的开发者之间测试这个接口的调用是否成功、数据是否能够正常获取等场景。 由于接口的协作涉及系统之间的开发人员之间的协作,因此通常需要在正常的开发时间之外留出与开发人员协作的时间。
接口的类型有多少种?
以上只是用简单的例子说明了接口的原理,实际上有很多类型的接口。 说明各种类型的接口因接口类型而异。1. 根据响应的机制可以分为同步、异步接口:
同步接口:在a系统请求b系统接口后,必须获得b系统接口的响应,然后才能执行以下操作:例如,要在登录操作时调用第三方平台接口(如wechat )进行登录,必须跳转到wechat进行认证并返回认证结果。
异步接口: a系统请求b系统接口后,无需等待源系统返回结果,即可进行下一步。
例如,滴滴打车后,司机点击退出日程后,无需等待银行支付成功后再开始下一个订单。 因为此时滴滴已经验证了司机、乘客的银行账户或支付宝(Alipay )账户,只要确认双方交易的合法性,就可以终止订单。
这个时候,我们看到已经支付成功了。 其实银行可能还没有提款。 滴滴后台将这笔交易流程交给银行,等银行核实后再扣款,进行支付操作。
2. 根据接口的触发形式可以分为分发、订阅接口
分发接口:在a系统生成新数据时分发到b系统(可以是多个)。例如,位于电子商务网站后台的客户管理系统在出现新的黑名单客户时,将数据分发到订单、推荐等各个系统,以便及时拦截这部分客户的订单。
订阅界面: b系统根据需要调用a系统的界面进行数据订阅。
例如,用户通过股票交易软件查询银行账户的余额时,会调用银行的余额查询接口,但股票交易软件本身并不保存该数据。
产品经理了解接口有什么用?
以上的不同类型的界面有不同的使用场景。 个人认为,产品经理不需要了解各种接口的实现原理,但需要了解在什么样的场景下应该使用什么样的接口,以提供更好的对外数据服务。个人认为,了解界面有以下好处。
明确各个系统之间的数据流转,特别是功能系统的产品经理,只有在知道了功能设计的目的、需要对外提供什么样的接口服务,需求设计阶段才能够考虑得更加全面;掌握开发总体工作量,而不局限于功能;另外,在安排项目计划时能够考虑到与周边系统联调的时间,计划安排才会更加合理;识别项目中的关键风险点,特别是一些关键接口、数据量大需要进行大数据压测的接口,需要尽早安排联调和测试,并且对周边配合的项目提出要求。产品经理如何写接口文档?
在妩媚的水池就可以找到不少现成的接口文档,可以参考腾讯开放平台上的API列表,这里简单总结几个要点:
声明接口字段和返回参数,字段需要声明是否必填、字段类型、长度以及处理规则;声明接口预估的数据量大小、调用频率等,以保证开发时考虑到接口的健壮性;声明接口的异常处理方式,如失败的数据是否重发、重发次数等等。在之前的产品设计过程中,还出现过配合系统双方的产品经理为了谁应该来写接口文档而争执过。后来定了一套标准,个人认为是比较合理的,供大家参考:
原则1:一般是由数据的需求方来编写接口需求文档。
原则2:如果该接口是一个分发接口,则由数据的提供方来编写接口需求文档。
总结:
好了,说到这里,已经把我个人这些年工作中所接触到的API接口简单介绍了一下。由于本人一直是做后端产品经理,因此对于前端的接口涉猎不多,不了解差异有多大,以上内容仅供后端产品经理参考,也希望大家能够对文中的一些错误及时指正。
另外,作为一名大数据的产品经理,大数据如何利用接口对外提供服务?后续总结出自己的一套方法论后再分享。
本文由 @LinKiD 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
【文章原创作者:阜宁网页制作公司 http://www.1234xp.com/funing.html 欢迎留下您的宝贵建议】