1、跨平臺性
所謂跨平臺是指我們的接口要能夠支持不同的終端，比如Android、iOS、windowsphone以及桌面軟件、網(wǎng)站等。如：不同的終端每頁顯示的記錄數(shù)不同。
采用通用的解決方案，比如通信協(xié)議就采用最常用的HTTP協(xié)議，如果是即時通信，可以采用開放的XMPP協(xié)議，做游戲的可以采用可靠的TCP協(xié)議，除非TCP不夠用了，再采用定制的UDP協(xié)議。
數(shù)據(jù)交換采用xml或者json格式或者webservice等等?？傊_到的目標就是讓不同的端能夠很方便的使用你的接口。
2、良好的響應速度
接口應該以最快的速度將數(shù)據(jù)返回給請求者,要達到的目標就是快，一個頁面，秒開最好，超過三秒就需要找找原因了。數(shù)據(jù)量按需分配，APP客戶端需要什么數(shù)據(jù)就返回什么數(shù)據(jù)，過多的數(shù)據(jù)量影響處理速度，最重要的是影響傳輸效率
3、接口要為移動客戶端考慮
比如，在移動端里，下拉刷新和上拉加載更多是很常見的功能，如果接口仍然按照傳統(tǒng)的web思路，
只提供按頁讀取的話，就會造成移動端的額外的數(shù)據(jù)請求和計算。 這時，接口就應該針對這兩種類型的操作提供額外的支持。
4、考慮移動端的網(wǎng)絡情況和耗電量
如果讓我們說出哪類app比較好，可能還不大好說，但是如果讓我們說出哪些app很差，我們肯定會說出那些體積很大、占用內(nèi)存多、界面很卡、費電的app 不好。對于網(wǎng)絡情況，接口應該具備為不同的網(wǎng)絡提供不同的內(nèi)容的能力如果我們能夠知道用戶的網(wǎng)絡情況，只有在wifi的情況下才給用戶傳輸封面圖、縮略圖 之類的，
是不是可以幫用戶節(jié)省很多流量呢
5、通用的數(shù)據(jù)交換格式
目前，對于接口和客戶端的數(shù)據(jù)交換格式，基本上就是三種，xml和json和webservice，而現(xiàn)在使用json的應該占大多數(shù)最麻煩的就是處理Date類型，因為JSON本身沒有Date類型，因此，JSON庫將Date類型的數(shù)據(jù)序列化時會轉(zhuǎn)為String。這時，不同環(huán)境， 不同平臺，以及用不同的JSON解析庫，轉(zhuǎn)換后的結(jié)果經(jīng)常會不同。
比如，你在開發(fā)機上可能得到的結(jié)果是”2016-1-1 17:11:11”，但放到服務器后結(jié)果卻變成了“Jan 1,2016 5:11:11 PM” ，客戶端進行反序列化時無疑會失敗。后來，我取消了所有Date類型，統(tǒng)一采用時間戳表示，就再沒有轉(zhuǎn)化的煩惱了。
另外，接口的開發(fā)人員有時候會將一些數(shù)據(jù)錯誤地轉(zhuǎn)換為了String，導致客戶端使用時因類型錯誤而異常。例如，本來是數(shù)字的1，被轉(zhuǎn)成 了"1"，客戶端做運算時就會出錯，或用switch判斷時也會出錯，或其他無法轉(zhuǎn)換的情況發(fā)生時;例如，為空時JSON正確地表示應該是null，但如 果轉(zhuǎn)為了String就變成了"null"，那問題就來了，我遇到的因為這個錯誤的轉(zhuǎn)換導致的程序奔潰已經(jīng)好幾次了，第一次的時候，查了一整天才定位到問題所在
6、接口統(tǒng)計功能
在做PC端網(wǎng)站的時候，我們都會給我們的網(wǎng)站加上個統(tǒng)計功能，要么自己寫統(tǒng)計系統(tǒng)，要么使用第三方的比如GA
移 動端接口API則需要我們自己實現(xiàn)統(tǒng)計功能，這時就需要我們盡可能多的收集客戶端的信息，除了傳統(tǒng)的IP、User-Agent之外，還應該收集一些移動 相關的信息，比如手機操作系統(tǒng)，是android還是ios，都是什么版本，用戶使用的網(wǎng)絡狀況，是2G、3G、4G還是WIFI。客戶端APP是什么版 本信息。
7、客戶端與服務端的肥瘦平衡
在移動開發(fā)中，由于客戶端的修改會很費時費力，特 別是IOS應用還要經(jīng)過Apple審核，另外，當前IOS開發(fā)人員、Android開發(fā)人員的人工成本普遍較高，人才緊缺，基于這兩點，能在服務器端實現(xiàn) 的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。
8、隱式用戶與顯式用戶
顯式用戶指的是，APP程序中有用戶系統(tǒng)，一個username、password正確的合法用戶，稱之為顯式的用戶，
通常顯式用戶都需要注冊，登錄以后能完成一些個人相關的操作。
隱式用戶指的是，APP程序本身就沒有用戶系統(tǒng)，或者一個在沒有登錄的情況下，使用我們APP的用戶。
在這種情況下，可以通過客戶端生成的UDID來標識一個用戶。
有了用戶信息，我們就能夠了解不同用戶的使用習慣，而不僅僅是全體用戶的一個整體的統(tǒng)計信息，
有了這些個體的信息之后，就可以做一些用戶分群、個性化推薦之類的事情。
9、安全問題
設計API第一個需要考慮的是API的安全機制。我負責的上一個項目，因為API的安全問題，就被人攻擊了兩次。之后經(jīng)過分析.
主要存在兩個漏洞： 一是因 為缺少對調(diào)用者進行安全驗證的方式，二是因為數(shù)據(jù)傳輸不夠安全。那么，制定API的安全機制，主要就是為了解決這兩個問題：保證API的調(diào)用者是經(jīng)過自己授權的App;保證數(shù)據(jù)傳輸?shù)陌踩?
