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