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請求的次數，比如多次請求，要看下能否合並，比如首頁，有好幾個區域，每個區域都有幾條數據。當然多次請求一樣可以實現，但是請求次數少，則服務器可以接受更多客戶端的請求。
1、API接口設計--前言