1、API接口设计--前言

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请求的次数,比如多次请求,要看下能否合并,比如首页,有好几个区域,每个区域都有几条数据。当然多次请求一样可以实现,但是请求次数少,则服务器可以接受更多客户端的请求。

原文地址:https://www.cnblogs.com/guangye/p/9369110.html

时间: 2024-11-07 23:54:06

1、API接口设计--前言的相关文章

atitit.基于http json api 接口设计 最佳实践 总结o7

atitit.基于http  json  api 接口设计 最佳实践 总结o7 1. 需求:::serverand android 端接口通讯 2 2. 接口开发的要点 2 2.1. 普通參数 meth,param, 2 2.2. 全部的參数定义 2 2.3. key,dynami key)韩式 static key? 2 2.4. 防篡改 sign 2 2.5. Encry加密 3 2.6. zip压缩:: 3 2.7. 首先压缩韩式加密??? 3 3. 选型大全:rim ,ws, http 

Web API接口设计(学习)

1.在接口定义中确定MVC的GET或者POST方式 由于我们整个Web API平台是基于MVC的基础上进行的API开发,因此整个Web API的接口,在定义的时候,一般需要显示来声明接口是[HttpGet]或者[HttpPost],虽然有些接口也可以不用声明,但是避免出现类似下面的错误信息,显式声明还是有好处的. 请求的资源不支持 http 方法“POST 例如在基类定义的查找对象接口如下所示. /// <summary> /// 查询数据库,检查是否存在指定ID的对象 /// </su

微信小程序的Web API接口设计及常见接口实现

微信小程序给我们提供了一个很好的开发平台,可以用于展现各种数据和实现丰富的功能,通过小程序的请求Web API 平台获取JSON数据后,可以在小程序界面上进行数据的动态展示.在数据的关键 一环中,我们设计和编写Web API平台是非常重要的,通过这个我们可以实现数据的集中控制和管理,本篇随笔介绍基于Asp.NET MVC的Web API接口层的设计和常见接口代码的展示,以便展示我们常规Web API接口层的接口代码设计.参数的处理等内容. 1.Web API整体性的架构设计 我们整体性的架构设计

php后台对接ios,安卓,API接口设计和实践完全攻略,涨薪必备技能

2016年12月29日13:45:27 关于接口设计要说的东西很多,可能写一个系列都可以,vsd图都得画很多张,但是由于个人时间和精力有限,所有有些东西后面再补充 说道接口设计第一反应就是restful api 请明白一点,这个只是设计指导思想,也就是设计风格 ,比如你需要遵循这些原则 原则条件REST 指的是一组架构约束条件和原则.满足这些约束条件和原则的应用程序或设计就是 RESTful.Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的.从客户端到服务

三分钟学会API接口设计 之 Compass 的Restful API 快速入门指南 -- 使用Flask框架

声明: 本博客欢迎转载,但请保留原作者信息! 作者:曾国仕 团队:华为杭州OpenStack团队 引子 大部分开源框架基本上都是使用Curl + RPC的方式构筑系统,以提供对外\对内的交互能力. 这种设计,本人认为更多地是出于层次化与模块化设计的考量,简化整个架构,使得开发轻量简单化. 本文主要介绍Compass的REST API的设计与实现. 通过本文档,读者至少能快速搭建一个属于自己的REST API 框架,并且能够基于该框架进行功能扩展以建立一个完整的系统. Compass的结构简介 图

优秀的API接口设计原则及方法(转)

一旦API发生变化,就可能对相关的调用者带来巨大的代价,用户需要排查所有调用的代码,需要调整所有与之相关的部分,这些工作对他们来说都是额外的.如果辛辛苦苦完成这些以后,还发现了相关的bug,那对用户的打击就更大.如果API经常发生变化,用户就会失去对提供方失去信心,从而也会影响目前的业务. 但是我们为什么还要修改API呢?为了API看起来更加漂亮?为了提供更多功能?为了提供更好的性能?还是仅仅觉得到了改变了时候了?对于用户来说,他们更愿意使用一个稳定但是看起来不那么时髦的API,这并不意味着我们

Web API接口设计经验总结

在Web API接口的开发过程中,我们可能会碰到各种各样的问题,我在前面两篇随笔<Web API应用架构在Winform混合框架中的应用(1)>.<Web API应用架构在Winform混合框架中的应用(2)--自定义异常结果的处理>也进行了总的介绍,在经过我的大量模块实践并成功运行后,总结了这篇随笔,希望对大家有所帮助. 1.在接口定义中确定MVC的GET或者POST方式 由于我们整个Web API平台是基于MVC的基础上进行的API开发,因此整个Web API的接口,在定义的时

API接口设计之 安全性 与 性能

接口安全性: 1. Token验证机制 通过用户名/密码调用授权接口获取Token,设置token有效期保持用户授权期间状态,可以使用token将信息保存在服务端,避免网络间传输,目的在于防止用户信息泄露,存储状态机. 2. 接口调用签名 由于前后端分离前端通过http请求调用后端接口,期间通过网络介质传输接口调用参数,黑客可能通过公共网域监听http请求信息,窃取调用接口参数信息,并从中查询规律,从而不通过客户端,直接通过http直接请求调用接口.这种情况下需要通过签名方式对一些敏感接口进行签

API接口设计之token、timestamp、sign具体实现

一.token 简介 Token:访问令牌access token, 用于接口中, 用于标识接口调用者的身份.凭证,减少用户名和密码的传输次数.一般情况下客户端(接口调用方)需要先向服务器端申请一个接口调用的账号,服务器会给出一个appId和一个key, key用于参数签名使用,注意key保存到客户端,需要做一些安全处理,防止泄露. Token的值一般是UUID,服务端生成Token后需要将token做为key,将一些和token关联的信息作为value保存到缓存服务器中(redis),当一个请