



























作为一个产品经理,要如何轻松搞定接口需求与文档?下面一起来看这篇有笔者整理分享的关于接口需求与文档相关内容的文章吧!推荐值得一看哦!

不懂技术的产品同学,天然的对技术相关的需求犯怵。比如说接口需求,接口是开发过程中避免不了的东西,作为产品经理,一定要知道。我一直负责集团的公共服务,所有服务都是通过「接口」与各个产品线对接。我也没有技术背景,当然在过程中遇到了一些问题,所以我总结了关于「接口需求」相关的内容。
说下:接口需求怎么提接口文档怎么看。
什么是接口?
看下边的例子:
微信获取用户基础信息接口:https://api.weixin.qq.com/cgi-bin/user/info/batchget?access_token=ACCESS_TOKEN
飞书查看全部工单接口:https://open.feishu.cn/open-apis/helpdesk/v1/tickets
这些 url链接就是接口地址。通过调用接口地址,获取到想要的东西。对于接口的作用,我划分为 3 种:
比如列表上有个「新增」的功能。前端开发出一个表单功能,当填完数据后,点击确定,前端会调用「新增数据接口」,将页面中录入的数据通过接口,传给后端,后端对传入的数据进行处理。接口处理完成后,会返回出具体的参数,前端根据返回的参数,给出对应的反馈信息。
比如当接口的校验没有通过时,则会通过接口返回出错误信息,前端会将错误信息在页面上进行提示。

同样的,对于删除数据、修改数据、查询数据等,都是通过接口的方式对数据进行处理。
两个系统之间进行数据同步。

比如我有个需求,需要使用到「系统用户信息」。对于「用户信息」,我司只有「账号系统」有,我需要和账号系统的产品经理沟通,对方提供给我一个接口文档,我们按照接口文档的要求进行数据同步。
同样的,当有需求要使用到你系统里的数据,也可以通过「接口」将数据同步给需求方。对于数据同步接口,数据同步的方式、数据同步的时机等等都是接口需求需要考虑到的内容。
这几点我们在下边详细说~
通过接口对外提供服务能力,可以满足不同的系统或应用程序之间进行功能调用。比如说身份证归属地查询服务,通过输入身份证号查询出归属地。当需要使用这个功能的时候,都可以调用「身份证归属地查询接口」,来实现这个功能。
另外支付服务、登录服务、获取收货地址等等,能够对外提供的公共服务,我们都可以做成公共接口对外使用。
很多同学认为接口是研发开发的,和产品没有关系,我之前也是这样想,后来发现这个并不对。接口是基于需求来开发的,里边涉及业务相关的内容,研发并不清楚具体的业务场景,如果产品经理不进行介入,就会导致接口的场景覆盖程度、扩展性受限。
不会提接口需求没关系,我们接下来细说:我们根据上边说的3 种接口用途,看下需求如何提。
这类接口一般和功能相关,也不涉及到跨系统,可以直接通过功能需求描述,不用特意地对接口进行说明。在研发开始前,前端与后端根据需求进行功能拆分,后端开发接口,前端开发页面,然后前后端进行接口联调。
无非 2 种:
我们先看「你向别人提供数据」
举个例子:一条产品线有个需求,想使用你系统的「人员信息」数据,在他们系统的页面中展示出「人员信息列表」
我们先从以下角度思考:
1)数据能否提供?
一般情况下,数据同步接口都可以做成公共接口,让每个业务方都能使用此接口。
2)支持哪种同步方式?
①业务方直接使用接口实时搜索,直接列表展示

业务方通过接口实时查询数据,并展示出结果,不将数据放到自己的数据库里。好处是每次查询都是最新数据。但是这种方式很不建议,当有业务方需要用到你的数据的时候,也需要提醒对方不要使用这种方式。用他方的数据同步接口去进行实时查询,如果数据同步接口性能扛不住,接口挂了,那业务也会挂。
当需要对数据进行二次加工处理,这种方式就不支持了,只能让数据同步接口加需求。但是一般的数据同步接口都是公共接口,不仅有一个业务方使用,当这个接口不满足你的需求的时候,公共接口不会根据你的需求做个性化调整。
②业务方通过接口将数据存储到自己的数据库中,对数据进行二次处理

通过数据同步接口,将数据同步到自己的数据库中,单独存一份,与数据提供方做一层隔离。自己业务使用时,从自己的数据库中取数据。这样就算同步接口挂了,也不会影响自己的业务。同时,可以对获取的数据进行二次处理,灵活性更强。当业务方单独存储数据后,为了让两方数据保持一致,这就涉及到「数据更新」。
3)数据更新机制
分为2种:推、拉

推:有数据更新后,将更新的数据推给下游业务方。
①「推」有 2 种方式:
拉:下游业务方去主动拉取新的数据。
②「拉取」有 2 种方式:
4)数据更新范围
分为:全量更新、增量更新。它们的选择取决于需要同步的数据量以及更新的频率。
5)通过哪些字段获取数据能获取到哪些数据?
用哪个字段获取数据,意思是向接口传入哪些字段。能够获取到哪些数据,意思是接口会返回出哪些字段。会有2 个名词:
你可以理解为,接口就是个列表,这个列表的查询条件有哪些、查询结果有哪些。查询条件,就是接口的「入参」查询出的结果,就是接口的「出参」
①对于「入参」,在提需求时,产品经理需要考虑到:
②对于「出参」,产品经理需要考虑到:
③入参示例如:

④出参示例如:

到这里,我们的数据同步接口需求就可以了,更详细的可以看我提供的真实接口需求示例,领取方式在文末。
这个接口也比较常见,在很多服务对接时,都是直接使用接口对接。产品经理需要确定的接口中与业务相关的内容。
主要包括入参、出参、接口处理逻辑。
说个简单的例子:通过「身份证号查询归属地服务」
既然是通过「身份证号」查询,那「入参」里肯定就是「身份证号」
「返参」里有归属地,那「归属地」就涉及到省、市、区。
需求可以这样提:
1)入参:身份证号、必填、字符串、长度18位
2)出参:省份名称/直辖市、市/区、县
3)处理逻辑:
涉及到公共服务接口,就涉及到一个「接口性能需求」,这个不能落下,加上性能说明:
4)接口性能要求
示例如:
性能需求的可以看我之前的文章《5000字详解性能需求》。
在调用接口时,如果是收费接口,或者是需要调用次数做汇报,这个时候就得有「日志记录」需求。
5)日志记录
示例如:调用日志记录需求:数据库中存储入参、出参原始json。json 字段本期暂不进行结构化。记录字段至少包括:渠道 ID、入参 json、出参 json、创建时间、创建人、更新时间、更新人。其余应用字段研发自行判断。
json是一个文件格式,json中包含了字段名称与字段对应的值,大家可以自己学习下。
另外,如果存在一些报错情况,产品经理想记录,用于排查问题,可以加个「记录错误数据」的需求。
6)记录错误数据
示例如:
记录查询为空数据:当接口查询接口为空时,数据库存入查询结果为空的数据,用于补充「身份证号行政区域表」数据。记录字段包括:身份证号前6位、查询时间。
以上内容说完后,这就有一个新的问题:公共接口是谁都能接入吗?这又涉及到:接口鉴权——只能通过接口权限验证才能调用接口。接口鉴权需要产品提需求吗?
我的观点是不需要,让产品提还真提不出来。
我们现在采用的方式是:
当有业务方需要接入我们的公共接口时,我在后台新增一个渠道,通过渠道ID生成验签码,把渠道ID、验签码提供给业务方。业务方把渠道ID、验签码通过接口传入,具体怎么接口验签,研发自己对。到这,接口需求包含以上内容,我认为就OK了。当然,还有其他的几个内容。
有 GET、POST 等,我认为这个让研发去定,只要能满足需求,这就够了。我唯一一次遇到过的问题是前端来找我,说 GET 请求字符超长,问我怎么处理。因为 GET 请求是在 url 后边拼接请求参数,最多支持 2048 个字符。

我们分析后发现在实际场景里,会有入参很多的情况,就会导致请求 url 超长。我也不知道怎么处理,问后端,后端说改成 POST。因为POST在是使用json传入参数,不涉及到字符超长的情况。
8)接口分页:
就是分页返回数据,可以理解为列表中的分页,每页返回10条数据。当数据量过大的时候,响应时间不会过长。一般情况下,返回数据很多时,都可以添加分页。
9)接口请求频次
就是对接口加个限制,防止服务过载,避免服务崩溃。具体的限制策略可以根据业务需求来制定,如 1min 内最多调用 10 次,1天1万次等。当次数超过限制后,再调用时则报错。
以上,我们就说完了「接口需求怎么提」,接下来说「接口文档」。
接口文档是对外提供的详细的接口接入说明,主要用于描述可提供的接口信息。
所有开发人员都将根据这份文档进行后续的开发工作。
接口文档中内容一般有:
我们可以看到一份接口文档中包含了整个接口中的全部信息。产品经理不需要自己写接口文档,而是应该由研发编写。产品经理在此基础上填写与业务相关的说明
包括:
同样的,当我们看接口文档时,产品经理也需要关注的是和业务相关的内容即可。
看接口文档的目的是为了我们自己的需求,要确定接口能够满足我们的需求。在接口能够支持的情况下,更好的去设计需求。
所以我们要关注以下内容:
接口描述:了解接口的作用与能力。
入参:
出参:
示例如:有个新需求:后台中的发起审核时,要在钉钉群里发送一条群通知。
这个时候就涉及到钉钉能否支持。
那就去「钉钉开放平台」看下,钉钉提供了一个「机器人发送群聊消息」的公共接口。

然后去看这个接口描述,首先可以知道钉钉是可以支持的。
接着继续看接口中的入参、返参,里边说明了可以支持的消息模版,就可以结合我的需求选择一个消息模板,并确定整体需求设计方案。

至于接口怎么接,让研发研究去就行了。
接口需求在对于没有技术背景的同学会有一些迷茫,但是理清楚其实也没什么。你可以去钉钉开放平台、飞书开放平台、微信开发平台、抖音开放平台等很多地方去看看这些大厂的接口文档,看多了也会知道接口是怎么回事。
我们在做产品的时候,不要只关注原型页面这些表面的东西,同时也需要考虑接口的设计和使用,尤其是做公共服务、接入三方服务的时候,你无法避免的要关注接口。就算没有接口需求,我们了解接口后,也能更好的与开发人员进行有效的沟通和协作。
专栏作家
王大鹿,公众号:产品大鹿,人人都是产品经理专栏作家。关注医疗领域,擅长原型设计、需求分析和方案设计,分享能落地的工作技能~
本文原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。