1. API版本控制

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

[[69599]]

API就如同你的應(yīng)用后端與使用它的應(yīng)用之間存在一個約定。沒有適當?shù)陌姹究刂?，一方可以在另一方完全不知曉的情況下更改約定，那么，你將處于非常危險的 境地。對多個API版本提供支持，可以讓那些沒有及時升級應(yīng)用的用戶繼續(xù)使用，而通過App的最新版，可以讓你了解到最新API的所有變化。

在一款移動App中，API版本控制的重要性顯而易見。如果沒有API的版本控制，那么在對API進行修改時很容易會造成App停止運行，由此而造成的后果，會讓你哭天搶地追悔莫及。

2. 返回數(shù)據(jù)，不要超出需要

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

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

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

4. 堅決刪減多余的步驟/請求

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

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

• 提供的認證信息有效，API響應(yīng)一個會話令牌。
• 當數(shù)據(jù)請求發(fā)出時，該會話令牌通過。

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

這樣做的好處是當用戶使用App時，響應(yīng)速度更快，使用流量也更少。對于開發(fā)者而言，這可以讓應(yīng)用代碼更為簡單，如此一來，既降低了開發(fā)成本，也可以減少維護費用，皆大歡喜，何樂而不為呢。

#p#

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

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

[[69600]]

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

6. 重中之重：安全性

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

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

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

7. 認真計劃并執(zhí)行你的緩存策略

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

• 服務(wù)器端

如果你在服務(wù)器上進行緩存，那么，就要確保當遭遇宕機之時，你能有辦法強行停用服務(wù)。

• 客戶端

除了服務(wù)器端，使用API的應(yīng)用客戶端也要確保實施適當?shù)木彺娌呗?。如果你在使用最新返回的?shù)據(jù)時請求調(diào)用，那么你可以節(jié)省一定的時間及資源。如果你在初始化時避免執(zhí)行調(diào)用操作，則會節(jié)省更多的時間和資源。

8. 整合分析

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

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

9. 究竟如何命名？請認真思考！

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

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

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