Appearance
基础篇 1-小程序需求分析与基础设计
基础篇 1：业务需求分析与基础设计
本小节，我们开始进入小册的正题。首先带领同学们站在一个业务的通用视角，寻找业务问题背后的通性，帮助同学们举一反三。而后再引出一个待实战解决的典型案例，完成基础接口设计，为后面的小节内容做准备。
业务需求分析
万丈高楼平地起，大多数的商业项目，都离不开一些常见的业务功能：
- 用户身份的建立
- 服务接口针对用户的验证
- 获取列表类数据
- 分页列表数据
- 获取单条数据详情
- 提交业务数据
概而言之，用户权鉴与 业务的增删改查（CURD）。
典型案例-新闻媒体流
以经典的新闻媒体流为例。我们往往会先访问到最新的新闻文章列表，列表条目较多时，需要对列表进行分页。当我们对某条新闻产生兴趣后，会进入新闻的详情。随着对详情内容的阅读，我们希望对新闻的内容进行互动，表达自我。无论是一个简单的点赞、还是五星好评、或是小段的评论，这些行为往往需要有一个明确的用户身份来分辨互动的来源，而后创建提交互动行为的数据，完成最终的业务设计实现。
典型案例-中后台管理系统
伴随数字化赋能，各行各业都充斥着大大小小的中后台管理系统。抛开管理系统对用户角色权限设计，常规的基础业务，往往只是把用户验证的流程提前了，只有在登录页校验通过的用户，才允许使用系统中的后续功能。而进入系统之后，无论是 Dashboard 控制台，还是大量的业务数据列表，针对单条数据列表的详情进行新增（create）、编辑（update）、读取（read）、删除（delete），都与新闻媒体流的基础设计相仿，大同小异。
泛化案例-全领域基础业务系统
回想下我们这些年日常生活中所使用过的各种手机应用 APP，所涉及的产品领域，不外乎媒体、社交、电商、游戏、金融、教育等大板块领域。表象上不同领域的产品表现形态不同，而背后，不少常规的业务逻辑与数据关系原理其实也符合我们前文总结到的「用户权鉴」与「业务增删改查」的基本框架。
| 领域 | 列表数据 | 单体数据 | 提交数据 |
|---|---|---|---|
| 媒体 | 新闻列表 | 新闻详情 | 评论点赞 |
| 社交 | 好友列表 | 好友详情 | 好友留言 |
| 电商 | 商品列表 | 商品详情 | 商品下单购买 |
| 游戏 | 队伍的成员列表 | 队伍的成员角色属性 | 成员角色属性的养成升级 |
| 金融 | 理财产品列表 | 理财产品详情 | 理财商品购买 |
| 教育 | 课程列表 | 课程内容详情 | 课程内容答题互动 |
目标案例
新零售，新经济
结合上述的项目案例剖析，本小册希望以时下热点的新零售与小程序的服务领域为案例背景，讲解如何利用 Node.js 的 hapi 服务框架，快速构建具有良好扩展性的 RESTful API 接口服务。案例的抽象原子模型为某外卖平台下的店铺、商品到外卖下单支付的一套完整链路，覆盖 hapi 的常用基础知识点。
目标案例的产品截图
案例实现的目标业务流程
- 用户访问店铺列表
展示店铺 名称、图标 URL - 用户访问目标店铺的商品列表
展示商品名称、图标 URL、商品单价 - 用户授权登录
获取用户姓名、openid、性别 - 选择需要选购的商品与数量
- 创建购物订单
- 创建支付订单
- 支付订单
- 完成订单
接口设计
RESTful 接口设计
作为小程序的接口服务，本案例采用业界流行的 RESTful 接口设计规范。在目前主流的三种 Web 服务交互方案中，REST 相比于 SOAP（Simple Object Access Protocol，简单对象访问协议）以及 XML-RPC 更加简单明了，无论是对 URL 的处理还是对 Payload 的编码，REST 都倾向于用更加简单轻量的方法设计和实现。
RESTful 的具体设计指南，同学们可以在阮一峰老师的《RESTful API 设计指南》手册中，找到更为系统的答案。
最为基础的设计规范是将所有的数据资源尽可能地名词化，而后对资源的具体操作，由 HTTP 动词来表示。最常用的有下面五个动词：
| 方法 | 描述 | 举例 | 资源路径 |
|---|---|---|---|
| GET（SELECT） | 从服务器取出资源（一项或多项） | 获取订单列表 | /orders |
| POST（CREATE） | 在服务器新建一个资源 | 创建一个订单 | /order |
| PUT（UPDATE） | 在服务器更新资源（客户端提供改变后的完整资源） | 修改订单信息 | /order/:orderId |
| PATCH（UPDATE） | 在服务器更新资源（客户端提供改变的属性） | 修改订单的信息 | /order/:orderId |
| DELETE（DELETE） | 从服务器删除资源 | 删除一条订单记录 | /order/:orderId |
目标案例的业务接口设计
| 方法 | 路径 | 是否需要登录 | 功能描述 |
|---|---|---|---|
| POST | /users/wx-login | 否 | 用户小程序授权登录 |
| GET | /shops | 否 | 店铺列表访问 |
| GET | /shops/{shopId}/goods | 否 | 某店铺商品列表访问 |
| POST | /orders | 是 | 创建购物订单，并获取订单编号 |
| POST | /orders/{orderId}/pay | 是 | 支付订单 |
小结
关键词：行业业务共性，外卖系统，RESTful 接口
本小节，我们通过行业业务的共性分析，最终选择了一个同学们再熟悉不过的外卖系统来作为教程案例切入，并完成了一套基于该外卖系统需求的基础 RESTful 接口设计。
思考：如果我们以「典型案例-新闻媒体流」 话题中聊到的场景，来设计一套新闻列表、新闻详情、创建评论点赞的接口，又该怎么设计呢？