1. API版本控制

無(wú)論何時(shí)，開(kāi)發(fā)者要想保證應(yīng)用正常運(yùn)轉(zhuǎn)，對(duì)API進(jìn)行修改總是不可避免的，可能只是對(duì)某些功能執(zhí)行添加、刪除或其他操作。當(dāng)遇到這種情況時(shí)，你就不得不暫停API部分的使用，或者允許正在使用的應(yīng)用對(duì)需要被返回的行為及響應(yīng)類(lèi)型有著明確的認(rèn)知。

[[69599]]

API就如同你的應(yīng)用后端與使用它的應(yīng)用之間存在一個(gè)約定。沒(méi)有適當(dāng)?shù)陌姹究刂疲环娇梢栽诹硪环酵耆恢獣缘那闆r下更改約定，那么，你將處于非常危險(xiǎn)的 境地。對(duì)多個(gè)API版本提供支持，可以讓那些沒(méi)有及時(shí)升級(jí)應(yīng)用的用戶(hù)繼續(xù)使用，而通過(guò)App的最新版，可以讓你了解到最新API的所有變化。

在一款移動(dòng)App中，API版本控制的重要性顯而易見(jiàn)。如果沒(méi)有API的版本控制，那么在對(duì)API進(jìn)行修改時(shí)很容易會(huì)造成App停止運(yùn)行，由此而造成的后果，會(huì)讓你哭天搶地追悔莫及。

2. 返回?cái)?shù)據(jù)，不要超出需要

在一定程度上，應(yīng)用與服務(wù)器之間發(fā)送的數(shù)據(jù)量將會(huì)影響發(fā)出請(qǐng)求及其響應(yīng)的時(shí)間。它所造成的影響不僅僅只是用戶(hù)緊盯加載頁(yè)面所花費(fèi)的時(shí)間，還可能包括加載頁(yè)面所花費(fèi)的流量。

3. 對(duì)發(fā)送及接收數(shù)據(jù)進(jìn)行壓縮

除了上述不要返回?cái)?shù)據(jù)超出需要之外，通過(guò)對(duì)發(fā)送及接收的數(shù)據(jù)進(jìn)行壓縮，可以讓你在速度和數(shù)據(jù)傳送上事半功倍，體驗(yàn)到更多的好處。

4. 堅(jiān)決刪減多余的步驟/請(qǐng)求

為了提供單獨(dú)的離散步驟而進(jìn)行API設(shè)計(jì)的情況很常見(jiàn)，但這是反映該服務(wù)是如何被使用的。因此在大多數(shù)情況下，這些離散步驟反而不是執(zhí)行移動(dòng)App最行之有效的方法。

讓我們來(lái)舉一個(gè)非常簡(jiǎn)單的例子。當(dāng)用戶(hù)在可以發(fā)送請(qǐng)求數(shù)據(jù)之前已經(jīng)提供了有效的認(rèn)證信息并登錄。這可能很是合情合理，我們可以將其理解為兩個(gè)單獨(dú)的步驟：

• 提供的認(rèn)證信息有效，API響應(yīng)一個(gè)會(huì)話(huà)令牌。
• 當(dāng)數(shù)據(jù)請(qǐng)求發(fā)出時(shí)，該會(huì)話(huà)令牌通過(guò)。

但事實(shí)上執(zhí)行此操作并不需要如此反復(fù)的過(guò)程。當(dāng)一個(gè)單一的請(qǐng)求發(fā)出時(shí)，通過(guò)認(rèn)證信息及其相關(guān)數(shù)據(jù)細(xì)節(jié)，數(shù)據(jù)及會(huì)話(huà)令牌在請(qǐng)求過(guò)程中同時(shí)被返回。

這樣做的好處是當(dāng)用戶(hù)使用App時(shí)，響應(yīng)速度更快，使用流量也更少。對(duì)于開(kāi)發(fā)者而言，這可以讓?xiě)?yīng)用代碼更為簡(jiǎn)單，如此一來(lái)，既降低了開(kāi)發(fā)成本，也可以減少維護(hù)費(fèi)用，皆大歡喜，何樂(lè)而不為呢。

#p#

5. 合并請(qǐng)求及響應(yīng)

除了作為身份驗(yàn)證或應(yīng)用啟動(dòng)過(guò)程中所發(fā)出的多重請(qǐng)求，在應(yīng)用程序的單頁(yè)或視圖中，為了對(duì)所有數(shù)據(jù)進(jìn)行檢索，都有可能發(fā)出多重請(qǐng)求。為頁(yè)面需要的所有數(shù)據(jù)建 立一個(gè)單一請(qǐng)求，其速度要比多重請(qǐng)求快得多，并且成本也更低。而速度及成本也正是用戶(hù)在使用應(yīng)用程序時(shí)首先考慮的兩大要素。

[[69600]]

再者，合并請(qǐng)求及響應(yīng)也可以讓?xiě)?yīng)用代碼更為簡(jiǎn)單，尤其是關(guān)于處理多重請(qǐng)求發(fā)出卻沒(méi)有成功的情況。如果將所有請(qǐng)求進(jìn)行合并，或化整為零，再多的異常情況也都變得非常簡(jiǎn)單，容易處理。

6. 重中之重：安全性

安全性是一個(gè)潛藏著危機(jī)可能隨時(shí)會(huì)迸發(fā)的復(fù)雜問(wèn)題，這也使得App對(duì)于安全問(wèn)題及時(shí)做出響應(yīng)難上加難。

因此，要時(shí)刻考慮以下內(nèi)容：

• 確保數(shù)據(jù)在傳輸過(guò)程中絕對(duì)安全；
• 數(shù)據(jù)等待傳輸時(shí)安全；
• 使用API不當(dāng)或未經(jīng)授權(quán)；
• 潛在的惡意或意外數(shù)據(jù)所帶來(lái)的后果。

7. 認(rèn)真計(jì)劃并執(zhí)行你的緩存策略

如果你的應(yīng)用API返回值不會(huì)經(jīng)常性改變，那一定要實(shí)施適當(dāng)?shù)木彺娌呗?。這可能會(huì)涉及到在內(nèi)存中保存數(shù)據(jù)，而不是反復(fù)地從硬盤(pán)中讀取數(shù)據(jù)，此外，還會(huì)對(duì)HTTP部分的緩存性能產(chǎn)生影響。

• 服務(wù)器端

如果你在服務(wù)器上進(jìn)行緩存，那么，就要確保當(dāng)遭遇宕機(jī)之時(shí)，你能有辦法強(qiáng)行停用服務(wù)。

• 客戶(hù)端

除了服務(wù)器端，使用API的應(yīng)用客戶(hù)端也要確保實(shí)施適當(dāng)?shù)木彺娌呗浴Ｈ绻阍谑褂米钚路祷氐臄?shù)據(jù)時(shí)請(qǐng)求調(diào)用，那么你可以節(jié)省一定的時(shí)間及資源。如果你在初始化時(shí)避免執(zhí)行調(diào)用操作，則會(huì)節(jié)省更多的時(shí)間和資源。

8. 整合分析

分析是理解一個(gè)App如何使用的非常重要的組成部分。在A(yíng)pp正常使用期間，對(duì)于調(diào)用而言，除了發(fā)出數(shù)據(jù)請(qǐng)求之外，做出一個(gè)分析服務(wù)是很常見(jiàn)的。例如，如 果應(yīng)用嘗試調(diào)用服務(wù)來(lái)刷新頁(yè)面顯示數(shù)據(jù)，然后用戶(hù)導(dǎo)航到該頁(yè)面，那么就會(huì)在添加一個(gè)單獨(dú)的追蹤/分析到該導(dǎo)航時(shí)產(chǎn)生冗余。

在最原始時(shí)期，使用API可以對(duì)App的使用方法及時(shí)間起到一個(gè)指示性的作用。與之對(duì)比的是豐富的分析工具及框架，它們可以提供用戶(hù)與App交互的非常 詳盡的信息。如果目前的你是介于兩者之間，那么，就請(qǐng)認(rèn)真思考如何進(jìn)行整合分析，或者僅僅只是為了追蹤應(yīng)用使用情況，而發(fā)出一個(gè)額外或者多余的調(diào)用。

9. 究竟如何命名？請(qǐng)認(rèn)真思考！

命名反映了你賦予API的方法、對(duì)象、屬性及參數(shù)，這也會(huì)極大地影響到使用API的人的理解方式。當(dāng)創(chuàng)建API時(shí)，無(wú)論用戶(hù)首先想到的是何種術(shù)語(yǔ)或用 語(yǔ)，就其本身而言，它就非常具有吸引力。就如同所有代碼一樣，你使用它的很大一部分原因在于A(yíng)PI如何被理解及其被期望的表現(xiàn)。如果名稱(chēng)起不好，就會(huì)讓人 非常困惑。困惑導(dǎo)致錯(cuò)誤，錯(cuò)誤導(dǎo)致bug，bug導(dǎo)致延遲及支持成本上升。因此，多花點(diǎn)時(shí)間在命名上吧！

10. 不要忘了你的隱私權(quán)保護(hù)政策及責(zé)任

如果你的應(yīng)用需要捕獲到用戶(hù)數(shù)據(jù)或登陸到服務(wù)器并記錄請(qǐng)求，那么你就必須制定一個(gè)隱私權(quán)保護(hù)政策，來(lái)向用戶(hù)詳細(xì)介紹你是如何使用這些數(shù)據(jù)信息的。此外，你還必須思考如何存儲(chǔ)及保護(hù)這些數(shù)據(jù)，尤其是如果它是屬于個(gè)人信息，或者與兒童相關(guān)，更需要慎重。