1API接口设计--前言

Posted 2020-12-25 guangye

1、场景描述

　　比如说我们要做一款APP，需要通过api接口给app提供数据。假设我们是做商城，比如我们卖书的。我们可以想象下这个APP大概有哪些内容：

　　1）首页：banner区域（可以是一些热门书籍的图片做推广）、本周热卖书籍区域、本月好评书籍区域、活动打折的书籍区域。。。

　　2）排行榜：比如第一季度热销榜、新书版。。。

　　3）书单：管理后台运营添加的书单，比如《程序员从入门到放弃》系列书单。。。

　　4）用户相关的：比如用户个人信息设置、订单管理、消息管理、收藏的书籍。。。

 

　　数据是保存在数据库中，考虑到高并发数据库的瓶颈，采用DB+缓存的服务器架构。

 

2、重要接口汇总

　　看似简单的一个app，需要调用的api接口是非常多的，总结下大概有这几类接口：

1）列表接口：比如书单里面的书籍列表、排行榜的书籍列表；

2）详情接口：书籍的详细信息；

3）评论接口：书籍评论（这里可能要求购买了的才能评论）、星标；

4）点赞接口：给书籍点赞、给书单点赞；

5）收藏接口：收藏书籍、收藏书单；

6）“相关”接口：比如书籍《php从入门到放弃》相关的有哪些书籍；

7）关注接口：关注某本书或者书籍作者，一旦某本书有打折或者作者有新书，会推消息等等。或者是用户间互相关注；

8）发布接口：比如用户可以发布书单。A用户发布了书单，B用户可以关注A用户，A用户再发布新书单，会给B用户推消息等等；

9）搜索接口：查询书籍、查询书单、查询用户等等

 

3、后台管理系统

1）书籍信息的来源：爬虫抓取的数据、运营人员在管理后台添加；

2）书籍的价格、库存等信息，是可以在后台设置；

3）书籍的分类、书籍的标签，像爬虫如果抓取不到的，运营可以手动设置；

4）书籍的排序：在管理后台设置，用于在app上展示的先后顺序；

5）书单管理：运营可以添加、可以设置展示/隐藏；用户提交的书单，在后台进行审核；

6）用户的评论：在后台审核；

备注：管理系统还有很多功能，简单先写这几个。

 

4、数据库设计

1）书籍表  book

• id 自增id，主键，书籍id
• title  标题
• description 描述
• author_id  作者id
• source 爬虫来源
• stock  库存
• price  价格
• status  状态：上架/下架
• sort  排序顺序
• create_time  添加时间
• create_user  添加者（运营账号id、爬虫来的话是指定一个运营id）
• update_time 修改时间
• update_user 修改者

2）作者表  book_author

• id  自增id，主键，作者id
• name    作者笔名
• birthday   出生年月
• sex    性别
• description   描述

3）分类表 book_category

• id  自增id，主键，分类id
• parent_id  父类id，顶级分类的父类id为0
• title  分类名称
• status  状态 是否可用
• create_time  添加时间
• create_user  添加者（运营账号id）
• update_time 修改时间
• update_user 修改者（运营账号id）

4）书籍和分类关系表   book_category_relation

（书籍绑定到最细的分类,为简单起见，假设一本书只绑定一个分类，假设书籍和分类是多对一关系）

• book_id  主键
• cate_id
• create_time  添加时间
• create_user  添加者（运营账号id）
• update_time 修改时间
• update_user 修改者（运营账号id）

5）标签表 book_tags

　　参考分类表

6）书籍和标签关系表 book_tags_relation

　　参考书籍和分类关系表，为简单起见，假设书籍和分类多对一关系，一个标签有多个书籍，一个书籍只有一个标签。

7）书单表 book_list

• id  自增id，主键，书单id
• title  书单名称
• description  描述
• status  状态：  发布/隐藏
• audit_status  审核状态
• audit_reason  审核理由（审核失败时需要填写）
• audit_time 审核时间
• audit_user  审核者（运营id）
• create_time   创建时间
• create_user  创建者（运营或者用户id）
• update_time  修改时间
• update_user  修改者（运营或用户id）

8）书单内容表（书单包含的书籍）  book_list_content

• id 自增id
• list_id  书单id
• book_id  书籍id
• reason  推荐理由
• star  推荐星级
• status  状态： 展示/隐藏
• sort  排序顺序
• create_time  添加时间
• create_user  添加者
• update_time   修改时间
• update_user  修改者

9）用户表  user

• id  自增id，主键，用户id
• user_name  用户名（登录用）
• nickname  用户昵称
• email 邮箱
• password  登录密码
• phone  电话
• sex  性别
• avatar  头像
• description  个性描述
• status  状态：待激活/已启用/黑名单
• create_time  账号创建时间

10）书籍点赞表  book_like

• id 自增id 主键
• book_id  书籍id
• user_id  用户id
• status 是否有效（因为不删除数据，所以增加这个状态字段）
• create_time  点赞时间
• update_time 更新时间

11）书籍收藏表  book_collect

　　参考 书籍点赞表

12）用户关注表（用户A关注用户B）  user_focus

• id  自增id  主键
• user_id  用户id（用户A）
• target_user_id 被关注的用户id（用户B）
• status  是否有效
• create_time  关注时间
• update_time 更新时间

备注：用户A和用户B互相关注，则表中有2条数据

13）订单表  order

• id 自增id  订单id
• order_sn  订单号
• user_id  用户id
• coupon_id  优惠券id
• discut_money 打折减免的价格
• origin_money 原价
• money  订单总价格
• status  订单状态： 待支付/已支付/拣货完毕/已发货/退货/已收货...
• comment 用户备注
• reason  退货理由 等
• create_time  订单生成时间
• update_time 修改时间

14）订单内容表  order_content

• id 自增id 主键
• order_id 订单id
• book_id  书籍id
• num  数量
• price 价格，原价
• amount 总价
• discut_money  折扣减免的价格
• activity_id  活动id（活动有折扣）

15）评论表  book_comment  （为简单起见假设评论只有对书籍的评论，没有对评论进行回复）

• id 自增id  主键
• book_id  书籍id
• user_id  用户id
• star  星级
• content  评论内容
• create_time 创建时间
• status 状态: 可用/删除
• update_time 修改时间
• audit_status  审核状态
• audit_reason 审核失败的原因
• audit_time 审核时间
• audit_user  审核者（运营id）

16）管理后台操作表 operation

• id 自增id 主键
• user_id 运营账号id
• content 内容
• operate_time 操作时间

备注：实际上不止这么少的表的，为简单起见，暂时就先列出这么多表

 

5、缓存设计

　　会在各个api接口中详细说明。

6、api接口设计思想

　　考虑到高并发时数据库的瓶颈，所以需要把请求的结果缓存起来。这里的策略是：

1）从缓存中获取数据，缓存中有数据则直接返回，或者做简单处理然后返回；

2）缓存没有数据，则从DB中查找数据，然后写回缓存；这种情况叫做“回源”。

3）缓存的key是需要设置过期时间的，避免数据一直占用内存；

4）过期时间的设计，最好是打乱，避免同一时间有大量的key过期导致请求集中去DB请求导致雪崩；

5）根据业务需求，“回源”的时候考虑申请到缓存锁的请求去数据库获取数据并更新缓存，其他请求则sleep一段时间（比如5毫秒10毫秒）然后再去缓存请求，如果请求还是没数据，可以继续等待或者直接返回空数据。

6）没有必要缓存起来的字段，不要缓存；

7）APP不需要用到的字段没有必要返回给APP，比如评论的审核时间、审核者，返回给APP是没用的，因为这些数据不需要展示出来，不会被用到；

8）减少api请求的次数，比如多次请求，要看下能否合并，比如首页，有好几个区域，每个区域都有几条数据。当然多次请求一样可以实现，但是请求次数少，则服务器可以接受更多客户端的请求。