前言

沒有最優(yōu)的方案，只有最適合的方案，本文指出對APP接口設(shè)計(jì)的一些規(guī)范與大家分享和共勉。
涉及到APP接口設(shè)計(jì)規(guī)范，設(shè)計(jì)案例的分享，和一些PHP編碼的要求，目的在于開發(fā)出性能優(yōu)異，結(jié)構(gòu)清晰，維護(hù)便捷，安全，和高拓展性的接口。拋磚引玉

經(jīng)驗(yàn)學(xué)習(xí)

在項(xiàng)目中，要做到融會貫通，首先就應(yīng)該做到多學(xué)習(xí)，學(xué)習(xí)大廠的經(jīng)驗(yàn)和總結(jié)，如果能避免到別家遇到的坑，那么就最好了，如果避免不到，那么也能做到心中運(yùn)籌帷幄。程序開發(fā)中有句很流行話就是，”不要重復(fù)造輪子”，要”時(shí)刻明確自己是搬磚民工,不是燒磚的窯”。

一、案例分析

新浪微博 open api

獲取用戶詳情接口設(shè)計(jì)?http://open.weibo.com/wiki/2/friendships/friends

{

? ? "users": [

? ? ? ? {

? ? ? ? ? ? "id": 1404376560,

? ? ? ? ? ? "screen_name": "zaku",

? ? ? ? ? ? "name": "zaku",

? ? ? ? ? ? "province": "11",

? ? ? ? ? ? "city": "5",

? ? ? ? ? ? "location": "北京 朝陽區(qū)",

? ? ? ? ? ? "description": "人生五十年，乃如夢如幻；有生斯有死，壯士復(fù)何憾。",

? ? ? ? ? ? "url": "http://blog.sina.com.cn/zaku",

? ? ? ? ? ? "profile_image_url": "http://tp1.sinaimg.cn/1404376560/50/0/1",

? ? ? ? ? ? "domain": "zaku",

? ? ? ? ? ? "gender": "m",

? ? ? ? ? ? "followers_count": 1204,

? ? ? ? ? ? "friends_count": 447,

? ? ? ? ? ? "statuses_count": 2908,

? ? ? ? ? ? "favourites_count": 0,

? ? ? ? ? ? "created_at": "Fri Aug 28 00:00:00 +0800 2009",

? ? ? ? ? ? "following": false,

? ? ? ? ? ? "allow_all_act_msg": false,

? ? ? ? ? ? "remark": "",

? ? ? ? ? ? "geo_enabled": true,

? ? ? ? ? ? "verified": false,

? ? ? ? ? ? "status": {

? ? ? ? ? ? ? ? "created_at": "Tue May 24 18:04:53 +0800 2011",

? ? ? ? ? ? ? ? "id": 11142488790,

? ? ? ? ? ? ? ? "text": "我的相機(jī)到了。",

? ? ? ? ? ? ? ? "source": "<a rel="nofollow">新浪微博</a>",

? ? ? ? ? ? ? ? "favorited": false,

? ? ? ? ? ? ? ? "truncated": false,

? ? ? ? ? ? ? ? "in_reply_to_status_id": "",

? ? ? ? ? ? ? ? "in_reply_to_user_id": "",

? ? ? ? ? ? ? ? "in_reply_to_screen_name": "",

? ? ? ? ? ? ? ? "geo": null,

? ? ? ? ? ? ? ? "mid": "5610221544300749636",

? ? ? ? ? ? ? ? "annotations": [],

? ? ? ? ? ? ? ? "reposts_count": 5,

? ? ? ? ? ? ? ? "comments_count": 8

? ? ? ? ? ? },

? ? ? ? ? ? "allow_all_comment": true,

? ? ? ? ? ? "avatar_large": "http://tp1.sinaimg.cn/1404376560/180/0/1",

? ? ? ? ? ? "verified_reason": "",

? ? ? ? ? ? "follow_me": false,

? ? ? ? ? ? "online_status": 0,

? ? ? ? ? ? "bi_followers_count": 215

? ? ? ? },

? ? ? ? ...

? ? ],

? ? "next_cursor": 5,

? ? "previous_cursor": 0,

? ? "total_number": 668

}

面向?qū)ο笤O(shè)計(jì):用戶是一個(gè)完整的對象，其中每個(gè)用戶包含一個(gè)最新微博的對象，微博對象也是一個(gè)相對完整的對象，按照新浪微博的APP接口設(shè)計(jì)，獲取每一個(gè)用戶列表，都能獲取到列表用戶的最新微博信息。

錯(cuò)誤信息的返回:主接口中沒有直接對錯(cuò)誤信息的定義，但凡是能夠獲取到信息，都認(rèn)為是正確，而錯(cuò)誤信息的定義則是用另一種數(shù)據(jù)格式來表示。

{

? ? "request" : "/statuses/home_timeline.json",

? ? "error_code" : "20502",

? ? "error" : "Need you follow uid."

}

錯(cuò)誤信息的說明:’request’表示當(dāng)前請求的接口;’error_code’表示錯(cuò)誤編號;’error’表示錯(cuò)誤的提示文字

淘寶開放平臺

查詢買家信息?http://open.taobao.com/docs/api.htm?spm=a219a.7629065.0.0.5Zpljz&apiId=21348

正常響應(yīng)：

{? "user_buyer_get_response":{

? ? ? ? "user":{

? ? ? ? ? ? "nick":"hz0799",

? ? ? ? ? ? "sex":"m",

? ? ? ? ? ? "avatar":"http://assets.taobaocdn.com/app/sns/img/default/avatar-120.png",

? ? ? ? ? ? "open_uid":"324324324"

? ? ? ? } } }

異常響應(yīng)

{

????"error_response":{

????????"sub_msg":"非法參數(shù)",

????????"code":50,

????????"sub_code":"isv.invalid-parameter",

????????"msg":"Remote service error" }

}?

錯(cuò)誤響應(yīng)也是通過錯(cuò)誤code來識別的，每個(gè)code對應(yīng)一個(gè)錯(cuò)誤內(nèi)容

其他開放API

除了上文說的響應(yīng)方式外，還有一種API響應(yīng)方式也是比較流行，代表者是百度,高德,支付寶等。?

- 百度舉例

{

? ? address: "CN|北京|北京|None|CHINANET|1|None",? ? #詳細(xì)地址信息?

? ? content:? ? #結(jié)構(gòu)信息?

? ? {?

? ? ? ? address: "北京市",? ? #簡要地址信息?

? ? ? ? address_detail:? ? #結(jié)構(gòu)化地址信息?

? ? ? ? {?

? ? ? ? ? ? city: "北京市",? ? #城市?

? ? ? ? ? ? city_code: 131,? ? #百度城市代碼?

? ? ? ? ? ? district: "",? ? #區(qū)縣?

? ? ? ? ? ? province: "北京市",? ? #省份?

? ? ? ? ? ? street: "",? ? #街道?

? ? ? ? ? ? street_number: ""? ? #門牌號?

? ? ? ? },?

? ? ? ? point:? ? #當(dāng)前城市中心點(diǎn)?

? ? ? ? {?

? ? ? ? ? ? x: "116.39564504",? ? #當(dāng)前城市中心點(diǎn)經(jīng)度

? ? ? ? ? ? y: "39.92998578"? ? #當(dāng)前城市中心點(diǎn)緯度

? ? ? ? }?

? ? },?

? ? status: 0? ? #結(jié)果狀態(tài)返回碼?

}

支付寶舉例

{

? ? "alipay_trade_precreate_response": {

? ? ? ? "code": "10000",

? ? ? ? "msg": "Success",

? ? ? ? "out_trade_no": "6823789339978248",

? ? ? ? "qr_code": "https://qr.alipay.com/bavh4wjlxf12tper3a"

? ? },

? ? "sign": "ERITJKEIJKJHKKKKKKKHJEREEEEEEEEEEE"

}

這類API相對新興設(shè)計(jì)，在API響應(yīng)上，不區(qū)分正確響應(yīng)和錯(cuò)誤響應(yīng)的結(jié)構(gòu)，采用統(tǒng)一返回方式，其中返回的code 來區(qū)分正確還是錯(cuò)誤，其中的message來分別給出正確和錯(cuò)誤的響應(yīng)消息。

我們自己的API響應(yīng)規(guī)則

選型我們自己使用的API相應(yīng)規(guī)則如下

正常響應(yīng)示例

{

? ? "status": 1,//狀態(tài)值是1

? ? "error_code": 0,//同時(shí)錯(cuò)誤代碼是0表示無錯(cuò)誤

? ? "message": "獲取成功",//提示操作成功信息

? ? "data": []//主體返回內(nèi)容

}

錯(cuò)誤響應(yīng)示例

{

? ? "status": 0,

? ? "error": 20102,//2:業(yè)務(wù)級錯(cuò)誤(1代碼系統(tǒng)級錯(cuò)誤)固定一個(gè)字符;01:指的是01這個(gè)業(yè)務(wù)比如保潔 固定? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?兩個(gè)字符;02具體錯(cuò)誤信息固定兩個(gè)字符，會整理成一個(gè)對照表格，前端需要翻譯? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?成友好的提示

? ? "message": "用戶id不能為空",//給前端程序員的不友好提示，指明錯(cuò)誤的原因

? ? "data": {}? //data字段固定

}

小結(jié)

API設(shè)計(jì)中，要根據(jù)自己的業(yè)務(wù)類型和面向群體來綜合考慮

都對錯(cuò)誤級別進(jìn)行了劃分，并用不同的錯(cuò)誤code來表示

API面向?qū)ο笤O(shè)計(jì)并不是面向頁面設(shè)計(jì)，這樣的API就具有了多端不同展示的能力

響應(yīng)主體設(shè)計(jì)中，個(gè)人比較傾向統(tǒng)一的返回，也就是現(xiàn)在我們正在使用的三段式返回，不同的客戶端不用去寫過多的兼容代碼和錯(cuò)誤處理，錯(cuò)誤處理全部由服務(wù)端來完成。

錯(cuò)誤處理，目前我們的錯(cuò)誤處理機(jī)制都還比較簡單，就APP而言，只有 ‘0’ ‘1’ ‘1001’,三種識別碼和對應(yīng)的中文提示內(nèi)容。如果我們后續(xù)要支持多種語言的提示，就必須使用error_code，然后由客戶端自行提示。

二、接口設(shè)計(jì)規(guī)范

與前端交互部分

這里概念的定義為與APP部分相互的部分，我們將從安全，版本兼容，命名規(guī)范，迭代，面向?qū)ο蟮榷鄠€(gè)方面說起

接口安全部分

在app的后端設(shè)計(jì)中，一個(gè)很重要的因素是考慮通訊的安全性。

避免信息的泄露，最簡單的方案是所有涉及到安全性的api請求，都必須要使用https協(xié)議。

因此，我們需要考慮的要點(diǎn)有：

1. 在app和后臺，都不能保存任何用戶密碼的明文

2. 在app和后臺通訊的過程中，怎么保證用戶信息的安全性

3. 在app中，根據(jù)安全考慮，用戶的操作分為兩類：

4. 用戶登錄

5. 注冊操作

6. 用戶的其他操作

在第一點(diǎn)，用戶登錄注冊操作中，是會出現(xiàn)用戶密碼，所以在這個(gè)過程中，必須要使用https通訊，保證通訊的安全。

在第二點(diǎn)，用戶的其他操作，怎么保證這部分通訊的安全呢？

在我們的設(shè)計(jì)中，是采用了公鑰加私鑰保證安全。用戶的id是公鑰，通過一定的算法對用戶的id進(jìn)行加密得到一個(gè)加密字符串是私鑰。當(dāng)用戶登錄或注冊后，通過https把公鑰加私鑰返回給app客戶端。

但這個(gè)方法有個(gè)缺點(diǎn)，當(dāng)別人截獲了這個(gè)url時(shí)可以重復(fù)使用，所以有個(gè)改進(jìn)方法是在傳遞的參數(shù)中增加時(shí)間戳，當(dāng)發(fā)現(xiàn)這個(gè)時(shí)間戳離現(xiàn)在的時(shí)間已經(jīng)很久了，就判斷這個(gè)url已經(jīng)失效了。但用時(shí)間戳怎么保證app的時(shí)間和服務(wù)器的時(shí)間同步？

可以在app每次啟動(dòng)和注冊登錄時(shí)和服務(wù)器同步時(shí)間，然后在app內(nèi)建一個(gè)時(shí)鐘，時(shí)間戳在這個(gè)app的內(nèi)部時(shí)鐘獲取，防止用戶修改了手機(jī)的時(shí)間。

當(dāng)然，這些操作做完了，也不能保證100%的安全，只能為攻擊增加成本。

另外，現(xiàn)在越來越多App取消了密碼登錄，而采用手機(jī)號+短信驗(yàn)證碼的登錄方式，我在當(dāng)前的項(xiàng)目中也采用了這種登錄方式。這種登錄方式有幾種好處：

不需要注冊，不需要修改密碼，也不需要因?yàn)橥浢艽a而重置密碼的操作了；

用戶不再需要記住密碼了，也不怕密碼泄露的問題了；

相對于密碼登錄其安全性明顯提高了。

效率

APP對服務(wù)器端要求是比較嚴(yán)格的，在移動(dòng)端有限的帶寬條件下或者弱網(wǎng)絡(luò)下，要求接口響應(yīng)速度要快，，拋開后端的開發(fā)框架效率來說，對數(shù)據(jù)要求也比較嚴(yán)格，如果能做到app需要什么數(shù)據(jù)就傳什么數(shù)據(jù)，不可多傳，過多的數(shù)據(jù)量影響處理速度，最重要的是影響傳輸效率那么自然效率是最高的，但是這之間也要有個(gè)取舍，效率和接口設(shè)計(jì)思想之間，后面我們會提到面向?qū)ο蟮脑O(shè)計(jì)思想。

面向?qū)ο蟮脑O(shè)計(jì)思想

Restful風(fēng)格：RESTfu設(shè)計(jì)原則,它被RoyFelding提出（在他的”基于網(wǎng)絡(luò)的軟件架構(gòu)”論文中第五章）。而REST的核心原則是將你的API拆分為邏輯上的資源。這些資源通過http被操作（GET,POST,PUT,DELETE)。但現(xiàn)在看，一般的操作只有兩種：GET ,POST。

這個(gè)設(shè)計(jì)原則最簡單的應(yīng)用就是面向?qū)ο笤O(shè)計(jì)而不是頁面來設(shè)計(jì)api。最開始的時(shí)候，app的一個(gè)頁面需要什么數(shù)據(jù)，api就返回什么數(shù)據(jù)。結(jié)果隨著app的UI不斷改版，需要的數(shù)據(jù)不斷變化，不停地修改api，最后當(dāng)api的改動(dòng)會影響以前的版本的時(shí)候，只能寫一個(gè)新的api版本，最后弄得api中有很多version/2,version/3這樣的標(biāo)志，惡夢!

但根據(jù)object來設(shè)計(jì)，又有一個(gè)問題，一個(gè)大object可能包含很多小object，是一個(gè)api返回全部小object，還是分為多個(gè)api返回？根據(jù)業(yè)務(wù)和技術(shù)，帶寬等仔細(xì)考慮吧。

目前我們的接口設(shè)計(jì)是根據(jù)業(yè)務(wù)來定制接口和返回，假設(shè)頁面上只顯示五個(gè)字段，那么后端就需要針對這個(gè)頁面進(jìn)行設(shè)計(jì)。

當(dāng)然這這樣的好處是顯而易見的，在和客戶端交互的過程中，傳輸?shù)臄?shù)據(jù)全是有用的數(shù)據(jù)，極大地節(jié)約了網(wǎng)絡(luò)資源，而且只需請求一個(gè)接口，接口就返回了所有界面顯示的數(shù)據(jù)，在弱網(wǎng)狀態(tài)下，加快響應(yīng)速度。

新浪微博的做法:打開個(gè)人中心，會分多次進(jìn)行請求，’users/counts’批量獲取用戶的粉絲數(shù)、關(guān)注數(shù)、微博數(shù),’users/domain_show’個(gè)性域名相關(guān),’users/show’獲取主要信息，這是比較極端的做法，僅供參考。

下面是一個(gè)簡單的例子

返回的數(shù)據(jù)結(jié)構(gòu)如下

{

? ? "brand_name": "奧迪",

? ? "car_model": "SUV",

? ? "emission_standard": "國五",

? ? "car_owner": {

? ? ? ? "name ": "張三 ",

? ? ? ? "driving_years": "5年",

? ? ? ? "id": "666"

? ? }

}

其中車主是一個(gè)對象，車子是一個(gè)對象，兩者是既有關(guān)系又相對獨(dú)立。?

總結(jié)建議是，新設(shè)計(jì)的接口，需要考慮到多端不同展示，盡可能的偏向于面向?qū)ο?，少量特殊處理可以面向頁面。?dāng)然，后端代碼上，都是以對象的形式存在，邏輯必須清楚。

API命名規(guī)則

其中一個(gè)原則，一看api名字就知道這個(gè)api是干啥。但是有個(gè)問題就是當(dāng)你要負(fù)責(zé)幾十甚至上百個(gè)api，你就知道不能”望名知api”是個(gè)什么樣的痛苦。

就拿一個(gè)接口來舉例吧

'/User/userRedDot/version/1'

這是我們在使用的一個(gè)接口，從接口名字來看，不難看出User這個(gè)是用戶相關(guān)的一個(gè)功能，然后userRedDot小駝峰命名指的是用戶小紅點(diǎn)，然后接口的版本號是第一版。以上4部分構(gòu)成了一個(gè)完整的接口命名。

傳參規(guī)則

接口文檔中是會注明不同的接口該使用不同的傳參方式

header參數(shù)部分:請求頭部一般放入鑒權(quán)的相關(guān)參數(shù)，比如用戶的token和簽名，設(shè)備id，APP的標(biāo)識，userAgent自定義等。

除去鑒權(quán)的參數(shù)，其他就是接口的入?yún)鬟f(文檔會注明傳遞方式):

1. 一維參數(shù) 按照POST/GET按照普通的form-data和urlencode方式即可

2. 多維參數(shù) 按照POST方式，并把body放入json的形式傳遞。

3. 新增數(shù)據(jù) POST

4. 獲取數(shù)據(jù)和修改數(shù)據(jù)用GET

接口使用規(guī)則

系統(tǒng)級接口需要獨(dú)立于業(yè)務(wù)之外使用，對于系統(tǒng)級接口，需遵循接口使用規(guī)則，對于非系統(tǒng)級接口，可由具體業(yè)務(wù)實(shí)現(xiàn)。但是安卓和ios需要統(tǒng)一。

打個(gè)比方，獲取用戶權(quán)限的接口，接口的使用規(guī)則由產(chǎn)品給出的，切換tab和從后臺返回。

再比如，獲取編輯用戶愛好，婚姻情況，個(gè)性簽名等篩選數(shù)據(jù)，按照接口使用規(guī)則，應(yīng)該在進(jìn)入用戶中心點(diǎn)設(shè)置的時(shí)候請求，現(xiàn)在是在打開APP地方的進(jìn)行請求，不符合接口使用規(guī)則。原因也在于以前沒有給出接口使用規(guī)則。

特殊處理的接口需要在接口文檔上注明使用規(guī)則，比如接口的先后順序，接口的使用環(huán)境和頻率。

對于接口返回，也需要安卓和ios進(jìn)行同步處理，操作成功和 操作失敗的信息提示，成功是都不處理還是都處理，失敗的提示信息怎么處理，操作失敗的時(shí)候提示信息需要明確。兩個(gè)客戶端不應(yīng)該存在不同的處理方案

兼容性原則

接口不可能永遠(yuǎn)不變，它會隨著需求的變化而做出相應(yīng)的變動(dòng)，這種變動(dòng)也可以理解為兼容或者不兼容。大部分情況下直接在這個(gè)接口上疊加版本號，并兼容舊版本。App的新版本開發(fā)傳參時(shí)則將傳入新版本的version。

接口的變化一般會有幾種：

1. 數(shù)據(jù)的變化，比如增加了舊版本不支持的數(shù)據(jù)類型(兼容:新增版本號,接口增量更新)

2. 參數(shù)的變化，比如新增了參數(shù)(兼容:新增版本號,接口增量更新)

3. 接口的廢棄，不再使用該接口了(不兼容:原接口指定版本廢棄，后端邏輯處理;原接口所有版本廢棄，如果是業(yè)務(wù)流程修改，則停用原接口，并新開接口)

4. 如果整個(gè)接口系統(tǒng)的根基都發(fā)生變動(dòng)的話，比如微博API，從OAuth1.0升級到OAuth2.0，整個(gè)API都進(jìn)行了升級，就無法兼容，只能進(jìn)行版本強(qiáng)制升級了。

有時(shí)候，一個(gè)接口的變動(dòng)還會影響到其他接口，但做的時(shí)候不一定能發(fā)現(xiàn)。

服務(wù)端異常處理

服務(wù)端的程序在運(yùn)行的時(shí)候，可能因?yàn)橐粋€(gè)數(shù)據(jù)的轉(zhuǎn)化或空指針異常什么的，都不能讓程序奔潰，需要捕獲異常并對異常進(jìn)行處理，并返回明確的數(shù)據(jù)狀態(tài)信息，不管是成功的，還是失敗的，都必須要有數(shù)據(jù)返回給APP客戶端，否則，接口的協(xié)議失去了所有的意義

app客戶端的語言 java和object-c都是強(qiáng)類型語言，所以怎么處理空值顯得特別重要，不合理的設(shè)計(jì)很容易造成app的閃退。

從后臺的角度來說，api中返回的數(shù)據(jù)中，正確值和空值的類型必須一樣，舉例，用戶名的字段是“realname”: “xxx”,如果用戶名為空，則應(yīng)該返回“realname”:”“。如果返回值是一個(gè)array，空數(shù)據(jù)則返回一個(gè)空array,如果返回值是一個(gè)對象，空數(shù)據(jù)則返回一個(gè)空對象,絕對禁止null值。

對于客戶端，必須用個(gè)全局的函數(shù)來處理所有api的返回?cái)?shù)據(jù)，需要有一個(gè)機(jī)制：對于某個(gè)客戶端需要數(shù)據(jù)，如果api中缺失，客戶端自動(dòng)補(bǔ)上并給予默認(rèn)值。

同時(shí)，在數(shù)據(jù)庫設(shè)計(jì)的時(shí)候，一個(gè)合理的設(shè)計(jì)必須是所有字段都有默認(rèn)值，不應(yīng)該允許null值。null在大量的語言和數(shù)據(jù)庫中，會帶來無窮的問題。

如果服務(wù)端是php，還有一個(gè)問題，php中數(shù)組和字典都是array，但是可以用(object)[]返回對象，但在java和object-c中是不一樣，這個(gè)問題一定要注意。

數(shù)據(jù)格式

補(bǔ)充說明下json的六種數(shù)據(jù)類型數(shù)據(jù)類型和約定

Number：整數(shù)或浮點(diǎn)數(shù)

String：字符串

Boolean：true 或 false

Array：數(shù)組包含在方括號[]中

Object：對象包含在大括號{}中

Null：空類型

前后端需要對數(shù)據(jù)類型進(jìn)行約定:

- 時(shí)間日期型數(shù)據(jù):直接返回格式化后的時(shí)間字符串或者直接返回時(shí)間戳

- 數(shù)字類型和文本類型:統(tǒng)一使用字符串格式

- 布爾值類型:統(tǒng)一使用字符串’0’和’1’來表示假和真

- 不返回Null類型數(shù)據(jù)

接口版本的設(shè)計(jì)

　　接口不可能一成不變，在不停迭代中，總會發(fā)生變化。接口的變化一般會有幾種：

數(shù)據(jù)的變化，比如增加了舊版本不支持的數(shù)據(jù)類型

參數(shù)的變化，比如新增了參數(shù)

接口的廢棄，不再使用該接口了

　　為了適應(yīng)這些變化，必須得做接口版本的設(shè)計(jì)。實(shí)現(xiàn)上，一般有兩種做法：

1. 每個(gè)接口有各自的版本，一般為接口添加個(gè)version的參數(shù)。

2. 整個(gè)接口系統(tǒng)有統(tǒng)一的版本，一般在URL中添加版本號，比如http://api.domain.com/v2。

　　大部分情況下會采用第一種方式，當(dāng)某一個(gè)接口有變動(dòng)時(shí)，在這個(gè)接口上疊加版本號，并兼容舊版本。App的新版本開發(fā)傳參時(shí)則將傳入新版本的version。

　　如果整個(gè)接口系統(tǒng)的根基都發(fā)生變動(dòng)的話，比如微博API，從OAuth1.0升級到OAuth2.0，整個(gè)API都進(jìn)行了升級。

　　有時(shí)候，一個(gè)接口的變動(dòng)還會影響到其他接口，但做的時(shí)候不一定能發(fā)現(xiàn)。因此，最好還要有一套完善的測試機(jī)制保證每次接口變更都能測試到所有相關(guān)層面。

APP后端代碼部分

面向?qū)ο笤O(shè)計(jì)，必須具有高拓展性來應(yīng)對各種需求的變更

抽象的顆粒度的把握，顆粒度必須很細(xì)，但是又不能太細(xì)了，但是實(shí)體對象必須是獨(dú)立的。

代碼層次結(jié)構(gòu)必須清晰，明確每一層干什么事情，做到適當(dāng)?shù)慕怦?，不依賴用不到的方法和函?shù)

面向接口設(shè)計(jì)，多人分工合作中，提供的代碼的最小單位是接口，使用者無需關(guān)注接口的內(nèi)部實(shí)現(xiàn)，提供接口的人后期維護(hù)該接口。

代碼重合部分，不難發(fā)現(xiàn)，目前系統(tǒng)中有很多功能類似的代碼，但是又發(fā)現(xiàn)這些代碼都有用處，維護(hù)這些代碼就非常痛苦，當(dāng)要改一個(gè)基礎(chǔ)的數(shù)據(jù)的時(shí)候，就會去改很多

SQL部分，優(yōu)化SQL查詢，提升查詢效率，杜絕使用join和寫復(fù)雜sql等不便于維護(hù)的代碼，不用jion和復(fù)雜sql之后能對系統(tǒng)的擴(kuò)展和二次開發(fā)有幫助，提高系統(tǒng)和數(shù)據(jù)庫的并發(fā)[目前能知道的是新浪微博已經(jīng)全面禁止使用join查詢了]。

待商榷問題

Herder管理:對herder的規(guī)劃和規(guī)范，包括設(shè)計(jì)和命名上，還有技術(shù)層面上的難題，尤其注意原生里面的內(nèi)嵌H5頁面

push到達(dá)率:目前的push能否滿足現(xiàn)狀的需求，如果不滿足，那么需要怎么樣才滿足。是否需要引進(jìn)新的第三方push

客戶端更新和熱更新:能否后續(xù)的功能用react來編寫，集成熱更新的能力，原生更新的邏輯梳理，和是否合理，不合理該如何調(diào)整。

權(quán)限和用戶權(quán)限:梳理現(xiàn)在的APP權(quán)限和用戶權(quán)限設(shè)計(jì)模式和交互模式，看是否合理，不合理的話，怎么調(diào)整。

接口依賴關(guān)系:接口之間原則上的依賴關(guān)系不能超過兩個(gè)，意思是一個(gè)接口需求的數(shù)據(jù)，最多只能從一個(gè)接口處獲取，如果情況特殊另說。