【技能get】“请求”与“返回”:请以你的名字呼唤我

0 评论 803 浏览 5 收藏 8 分钟

产品经理在工作中,有时候也需要接触到一些技术知识点,比如本文谈到的“请求和响应”。这篇文章里,作者就分享了请求/响应模型及其在实际工作中的应用场景,一起来看看吧。

我是一个没有技术背景的产品经理。在这里想和大家分享在0-1岁间我学到的最有用最重要的一个技术知识点,以及对这个知识点在实际工作中的应用场景。

一、请求/响应模型

客户端与服务端在虚拟的空间中沉睡,告诉他你的名字,这名字遂在万千数据中跑过,若得以验证,他便醒了。这就是请求/响应模型。

(图片来源:《产品经理必懂的技术那点儿事》作者:唐韧)

这个模型包含三部分:客户端、服务端以及中间的互联网。

以最基础的登录流程举例,客户端发起请求,把【用户名=ryan】和【密码=123】发送给服务端,服务端收到请求后进行判断处理,并将【code=200】【message=登录成功】返回给客户端,客户端根据收到的结果在页面上做出不同的展示,由此完成的一问一答,就是客户端与服务端的请求响应

平时开发们所说的“发起请求”“返回”就是基于这个模型的讨论。

在这个例子中,我们完成了请求和返回的过程,同时定义了两个主要的字段【用户名】和【密码】。我们常说,互联网就是由数据构成的。每一类数据都有一个名字,即字段名称。不同的字段携带着不同的值在互联网中传递流转,即是请求响应。

深刻地理解这个过程以及字段的含义(字段本质上是数据接口),是我在产品工作入门时学到的最重要的一点。

或许对尚未入门且不具备技术背景的同学来说,以上的叙述还有些抽象。学以致用,我们举几个应用场景。

二、工作中的应用场景

1. 需求阶段:PRD中的字段规则

好了,现在我们知道什么是字段了。对于初期的产品经理来说,我们设计完一个页面,应当具备把页面翻译成字段的能力(因为对于开发而言当他们阅读页面的时候也是在翻译成字段)。在我目前浅薄的经验里,字段说明加交互说明(操作和反馈信息等)可以解决需求文档中至少60%的规则说明。

举例,下图是常见的筛选组件:

(图片来源:作者自制)

在文档中我们可以这样描述:

(图片来源:作者自制)

一般来讲,对字段的说明包括字段名称、数据类型、默认值、是否必填、枚举值、输入形式等几列(这几列不是必须要有,要根据实际进行增减)

这种形式的字段说明有两个优点:

  • 第一,对于产品来说,它可以让你的文档简洁而富有秩序;
  • 第二,对于开发来说,这样的字段说明与开发设计时需要关注的点是一致的。

2. 开发阶段:他们说的接口文档是什么东西

接口文档,我一度认为是技术性非常强、如我这等小白不可涉及之物。在我了解完请求响应模型后才对它有了认识:接口文档,正是请求和响应的一次“书面记录”

(图片来源:作者自制)

以上是一个真实的接口文档的部分内容(已脱敏)。我们会发现文档的主体和上文中的字段说明有相似之处,因为“请求”实际上就是把一些参数(字段)传递给接口,“返回”则是从接口传回参数(字段),这正是接口文档中的入参和出参。

在我们团队中,产品经理并不直接参与接口文档的编写。那除了阅读之外我们还能怎样与接口文档产生“交互”呢?以下提供几个初级方式:

  • 描述业务/需求场景。对完成某些不常见任务的接口可以在备注/说明一栏里补充一下具体的需求场景。
  • 提供示例。对某些有特殊要求的字段提供一个仿真例子,有助于开发更好地设计数据类型。
  • 检查容易遗漏的细节。比如某些字段是否必填是否支持多选,有没有某些比较隐藏的功能点当前接口可能无法支持?

好了,现在你可以在简历上写上“熟悉接口文档”了。

3. 测试阶段:你也可以去判断bug的归属

如果你掌握了请求和返回,恭喜你,你就能协助测试判断一些简单的bug了。按下F12或者右键–检查网页(详细操作可以搜索关键词“网页调试”),可以查看页面发起的所有请求,以及返回的内容。

(图片来源:作者个人主页-人人都是产品经理网站)

想象一下,如果页面展示出现了问题,但返回的数据却是正常的,那么大概率问题出现在前端;如果返回的数据本身有错误或者没有返回,那么这时候你可以先去问下后端

作为最基础的互联网底层原理,99%的产品经理应该都对请求和响应非常熟悉了。但是对我这种无技术背景的产品小白来说,这篇写起来还是有点吃力(下篇写个轻松的),希望能对同样阶段的你有帮助。

本文由 @工凡 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!