【技能get】“请求”与“返回”：请以你的名字呼唤我
我是一个没有技术背景的产品经理。在这里想和大家分享在0-1岁间我学到的最有用最重要的一个技术知识点，以及对这个知识点在实际工作中的应用场景。
一、请求/响应模型
客户端与服务端在虚拟的空间中沉睡，告诉他你的名字，这名字遂在万千数据中跑过，若得以验证，他便醒了。这就是请求/响应模型。
（图片来源：《产品经理必懂的技术那点儿事》作者：唐韧）
这个模型包含三部分：客户端、服务端以及中间的互联网。
以最基础的登录流程举例，客户端发起请求，把【用户名=ryan】和【密码=123】发送给服务端，服务端收到请求后进行判断处理，并将【code=200】【message=登录成功】返回给客户端，客户端根据收到的结果在页面上做出不同的展示，由此完成的一问一答，就是客户端与服务端的请求响应。
平时开发们所说的“发起请求”“返回”就是基于这个模型的讨论。
在这个例子中，我们完成了请求和返回的过程，同时定义了两个主要的字段【用户名】和【密码】。我们常说，互联网就是由数据构成的。每一类数据都有一个名字，即字段名称。不同的字段携带着不同的值在互联网中传递流转，即是请求响应。
深刻地理解这个过程以及字段的含义（字段本质上是数据接口），是我在产品工作入门时学到的最重要的一点。
或许对尚未入门且不具备技术背景的同学来说，以上的叙述还有些抽象。学以致用，我们举几个应用场景。
二、工作中的应用场景
1. 需求阶段：PRD中的字段规则
好了，现在我们知道什么是字段了。对于初期的产品经理来说，我们设计完一个页面，应当具备把页面翻译成字段的能力（因为对于开发而言当他们阅读页面的时候也是在翻译成字段）。在我目前浅薄的经验里，字段说明加交互说明（操作和反馈信息等）可以解决需求文档中至少60%的规则说明。
举例，下图是常见的筛选组件：
（图片来源：作者自制）
在文档中我们可以这样描述：
（图片来源：作者自制）
一般来讲，对字段的说明包括字段名称、数据类型、默认值、是否必填、枚举值、输入形式等几列（这几列不是必须要有，要根据实际进行增减）。
这种形式的字段说明有两个优点：
- 第一，对于产品来说，它可以让你的文档简洁而富有秩序；
- 第二，对于开发来说，这样的字段说明与开发设计时需要关注的点是一致的。
2. 开发阶段：他们说的接口文档是什么东西
接口文档，我一度认为是技术性非常强、如我这等小白不可涉及之物。在我了解完请求响应模型后才对它有了认识：接口文档，正是请求和响应的一次“书面记录”。
（图片来源：作者自制）
以上是一个真实的接口文档的部分内容（已脱敏）。我们会发现文档的主体和上文中的字段说明有相似之处，因为“请求”实际上就是把一些参数（字段）传递给接口，“返回”则是从接口传回参数（字段），这正是接口文档中的入参和出参。
在我们团队中，产品经理并不直接参与接口文档的编写。那除了阅读之外我们还能怎样与接口文档产生“交互”呢？以下提供几个初级方式：
- 描述业务/需求场景。对完成某些不常见任务的接口可以在备注/说明一栏里补充一下具体的需求场景。
- 提供示例。对某些有特殊要求的字段提供一个仿真例子，有助于开发更好地设计数据类型。
- 检查容易遗漏的细节。比如某些字段是否必填是否支持多选，有没有某些比较隐藏的功能点当前接口可能无法支持？
好了，现在你可以在简历上写上“熟悉接口文档”了。
3. 测试阶段：你也可以去判断bug的归属
如果你掌握了请求和返回，恭喜你，你就能协助测试判断一些简单的bug了。按下F12或者右键–检查网页（详细操作可以搜索关键词“网页调试”），可以查看页面发起的所有请求，以及返回的内容。
想象一下，如果页面展示出现了问题，但返回的数据却是正常的，那么大概率问题出现在前端；如果返回的数据本身有错误或者没有返回，那么这时候你可以先去问下后端。
作为最基础的互联网底层原理，99%的产品经理应该都对请求和响应非常熟悉了。但是对我这种无技术背景的产品小白来说，这篇写起来还是有点吃力（下篇写个轻松的），希望能对同样阶段的你有帮助。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
