一：APP接口存在幾個問題值得思考
1、跨平臺性
? ? ? 所謂跨平臺是指我們的接口要能夠支持不同的終端奥裸，比如android险掀、ios、windowsphone以及桌面軟件湾宙、網(wǎng)站等樟氢，一套接口，支持多端侠鳄，就像當年Java的口號一樣“Write Once,Run Anywhere”埠啃。當然從本質(zhì)上講，服務(wù)器端的接口跟終端是沒有太大關(guān)系的伟恶，但接口應(yīng)該考慮到不同端的接入成本碴开，應(yīng)根據(jù)項目或公司自身情況應(yīng)該做相應(yīng)的版本處理。采用通用的解決方案博秫，比如通信協(xié)議就采用最常用的HTTP協(xié)議潦牛，如果是即時通信，可以采用開放的XMPP協(xié)議挡育，做游戲的可以采用可靠的TCP協(xié)議巴碗，除非TCP不夠用了，再采用定制的UDP協(xié)議即寒。數(shù)據(jù)交換采用xml或者json格式等等良价，因自己所處環(huán)境具體情況而定≥锏總之，要達到的目標就是讓不同的端能夠很方便的使用你的接口蚣常。已知現(xiàn)實情況：
1：正規(guī)的App設(shè)計接口規(guī)范文檔市咽，已App界面為功能導(dǎo)向是設(shè)計移動端接口。意義：后端開發(fā)成本高抵蚊，接口頁面規(guī)范可查施绎，App接入成本低，App維護性高贞绳。溝通成本低谷醉，對業(yè)務(wù)理解能力門檻低！
2：另類的設(shè)計冈闭，已后端業(yè)務(wù)為導(dǎo)向俱尼，提供大而全的api設(shè)計接口，以滿足所有端的所有需求萎攒，接口傳入各種各樣的配置和參數(shù),遇八。意義： 后端開發(fā)成本低矛绘，App接入成本很高，App后期的維護性低刃永，維護成本高货矮，溝通成本高，對業(yè)務(wù)的理解能力門檻高斯够！
問題：Api設(shè)計所提的的一套接口適應(yīng)多端的精髓和初衷到底是什么囚玫？
2、客戶端與服務(wù)端的肥瘦平衡
? ? ? 在以前C/S读规、B/S架構(gòu)時抓督，就已多次討論過這個問題，客戶端是瘦點好還是肥點好掖桦，當然也沒有固定答案本昏，需要自己根據(jù)實際情況去做權(quán)衡∏雇簦客觀原因涌穆，在移動APP開發(fā)中，由于客戶端的修改會很費時費力雀久，一是App應(yīng)用需要經(jīng)過各種渠道審核宿稀，耗費時間。更新修復(fù)問題的時間成本過高赖捌。另外祝沸，當前IOS開發(fā)人員、Android開發(fā)人員的人工成本普遍較高越庇，人才緊缺罩锐，基于這兩點，能在服務(wù)器端實現(xiàn)的功能就不要放在客戶端卤唉，畢竟服務(wù)器端程序的修改要比客戶端方便涩惑、靈活、快捷的多桑驱。
問題：作為項目負責人或技術(shù)負責人該站在什么角度去看這個問題竭恬？肥瘦平衡最終追求的是什么？
3熬的、考慮移動端的網(wǎng)絡(luò)情況和耗電量
? ? 對于移動APP開發(fā)者來說痊硕， 網(wǎng)絡(luò)流量和電池電量是不得不考慮的問題。不過押框，您也許會說岔绸，這些跟接口沒啥關(guān)系吧，服務(wù)器端的接口還能管得了客戶端的網(wǎng)絡(luò)流量和電量？
? ? 1：）對于網(wǎng)絡(luò)情況亭螟，接口應(yīng)該具備為不同的網(wǎng)絡(luò)提供不同的內(nèi)容的能力挡鞍， 通常，移動端的上網(wǎng)方式無非是2G（GSM预烙、GPRS墨微、EDGE）、3G（CDMA扁掸、TDSCDMA翘县、WCDMA）、4G/5G谴分、WIFI锈麸。設(shè)想一下，如果用戶在流量需要花錢的情況下牺蹄，你的app給用戶展示了視頻忘伞、音頻、大量的圖片和大量無用數(shù)據(jù)（接口中存在大量跟app頁面無關(guān)的數(shù)據(jù)沙兰，俗稱大而全的接口）氓奈。而沒有通知用戶的情況下用戶會怎么想，畢竟國內(nèi)的流量費用還是很貴的鼎天，應(yīng)在不同的環(huán)境下提供不同的策略舀奶。
? ? 2：）對于電量，app的哪些方面會消耗電量斋射？比如app有大量的計算育勺、有很炫的視覺畫面都會消耗電量， 另外罗岖，不斷的移動網(wǎng)絡(luò)鏈接也會消耗大量的電量涧至，我們都知道移動網(wǎng)絡(luò)是通過無線電波來通訊的，那么發(fā)射裝置就需要消耗一定的電量來發(fā)射和接收無線信號桑包。特別的是化借，頻繁的鏈接會不斷的切換網(wǎng)絡(luò)設(shè)備與移動基站之間連接狀態(tài)，這都會消耗一部分電量捡多。
所以，對于接口而言铐炫，盡量用少的鏈接傳輸多的數(shù)據(jù)垒手，和盡量少的數(shù)據(jù)接收交互。
問題：3G/4G/5G時代需不需要考慮用戶的流量成本倒信？? 對App的追求和定位到底是什么科贬，只是滿足功能需求，還是提供優(yōu)質(zhì)服務(wù)體驗？
4：接口需不需要要為移動客戶端考慮榜掌，做相應(yīng)的API適配
? ? ? 1：一種聲音是不需要优妙，后端寫一套接口，不管是web端,Android,ios,wap等都調(diào)用相同的接口憎账，后端維護簡單套硼。
? ? ? 2：另一種聲音是需要，要依據(jù)不同場景胞皱，開發(fā)相應(yīng)的API接口（如移動端邪意，web端等）
? ? ? 相對于我目前而言第二種較為合理。提供一下例證反砌，歡迎探討雾鬼。
? ? ? 接口不僅僅是提供數(shù)據(jù)和功能就完事了，更應(yīng)該充分考慮移動端的特性宴树，為移動端提供更加方便策菜、快捷的接口。
比如酒贬，在移動端里又憨，下拉刷新和上拉加載更多是很常見的功能，如果接口仍然按照傳統(tǒng)的web思路同衣，
只提供按頁讀取的話竟块，就會造成移動端的額外的數(shù)據(jù)請求和計算。 這時耐齐，接口就應(yīng)該針對這兩種類型的操作提供額外的支持浪秘。
再比如，對于一個新聞閱讀類的app來說埠况，最新的新聞列表里的文章耸携，特別是前幾條，用戶很容易點擊進去看辕翰，而后面的老的文章列表夺衍，一來用戶下滑加載好幾頁的情況較少，二來過時的新聞用戶也很少點喜命。如果沟沙，接口在返回新聞列表時，對于最新的列表壁榕，可以直接把文章的正文（或者部分正文矛紫，比如一屏的內(nèi)容）信息一起傳給客戶端，
這樣牌里，用戶在打開新聞詳情頁的時候颊咬，就不用再從服務(wù)器端獲取了，自然可以做到秒開。
比如訪問第一頁時喳篇，接口可以返回文章內(nèi)容敞临，如下所示 ，content=1表示加載文章內(nèi)容
newslist?page=1&pagesize=20&content=1
其他頁時麸澜，newslist?page=5&pagesize=20&content=0 ,不用加載文章內(nèi)容挺尿。
當然，客戶端要跟接口做好配合痰憎，搭配好票髓，才能最大化的提高性能。
比如铣耘，移動端都有左右滑動來看上一篇洽沟、下一篇文章或者圖片的功能，
如果蜗细，當用戶請求某篇文章的時候裆操，服務(wù)器端順便也把下一篇文章的內(nèi)容返回回來了，
那么當用戶看下一篇的時候炉媒，是不是就很快了呢踪区。
當然這種preload的方案也不能濫用，如果預(yù)加載數(shù)據(jù)的命中率較低的話吊骤，也不行缎岗，白白浪費了很多的流量。
二：APP接口設(shè)計構(gòu)思應(yīng)該思考的問題
1 ：實用性
編寫接口API應(yīng)遵從實用性原則白粉。
? ? ? 1）传泊、數(shù)據(jù)格式
? ? ? 推薦使用JSON格式數(shù)據(jù)，因為JSON有較好的跨平臺性鸭巴，以及數(shù)據(jù)格式占用字節(jié)數(shù)較少眷细，當然也可采用XML、TEXT作為程序開發(fā)輔助鹃祖。
如：json服務(wù)器返回的數(shù)據(jù)結(jié)構(gòu)溪椎，一般為：
{
code：200
message: “success”
data: { key1: value1, key2: value2, … } }
code: 狀態(tài)碼，200表示成功恬口，非200表示各種不同的錯誤
message: 描述信息校读，成功時為”success”，錯誤時則是錯誤信息
data: 成功時返回的數(shù)據(jù)祖能，類型為對象地熄、或數(shù)組... , 因此，data必須返回相應(yīng)經(jīng)過初始化的格式芯杀，數(shù)組如：[],對象：{}的格式，如果傳入一個null,如果對象類型變成了String類型，那么肯定是報錯的揭厚。? ?
? ? ? 2）却特、接口執(zhí)行效率（接口訪問速度）
? ? ? APP有別于WEB服務(wù)，對服務(wù)器端要求是比較嚴格的筛圆，在移動端有限的帶寬條件下裂明，要求接口響應(yīng)速度要快，對數(shù)據(jù)要求也比較嚴格太援，app需要什么數(shù)據(jù)就傳什么數(shù)據(jù)闽晦，不可多傳，過多的數(shù)據(jù)量影響處理速度提岔，最重要的是影響傳輸效率和浪費用戶流量仙蛉。接口要規(guī)范，以面向?qū)ο蟮乃枷朐O(shè)計接口碱蒙。
? ? ? 3）荠瘪、API緩存
? ? ? 對APP運行的體驗和流暢性來說，適當?shù)木彺姹容^重要赛惩，不管是文件緩存還是memcache緩存哀墓，能讓用戶感知不知不覺中對App產(chǎn)生好的體驗。
2 ：易用性
? ? ? ? 編寫接口API應(yīng)遵從實用性原則喷兼。
? ? ? 1）篮绰、接口、參數(shù)命名準確：無論是接口還是參數(shù)季惯，命名都應(yīng)該有意義吠各，讓人一目了然。（接口推薦根據(jù)APP效果圖欄目進行命名）
? ? ? ? 2）星瘾、一個頁面盡可能就用一個接口： 現(xiàn)在很多的APP頁面都有廣告走孽、焦點圖、文章列表等琳状，對于這些不同格式的數(shù)據(jù)磕瓷，不可能都分配一個接口，這樣加大了APP請求接口數(shù)念逞，影響響應(yīng)速度困食。建議服務(wù)器端盡可能處理好數(shù)據(jù)后通過一個接口返回給APP客戶端，或把相似的部分功能合并已達到想要的效果翎承，盡量不要出現(xiàn)一個頁面七八上十個接口的情況硕盹。
? ? ? ? 3）、接口數(shù)據(jù)叨咖、狀態(tài)：接口必須提供明確的數(shù)據(jù)狀態(tài)信息瘩例，不管是成功的啊胶，還是失敗的，都必須返回給APP客戶端垛贤，系統(tǒng)級異常焰坪，業(yè)務(wù)級異常，參數(shù)及異常都應(yīng)有所體現(xiàn)聘惦。否則某饰，接口的協(xié)議失去了所有的意義
? ? ? 4）、接口要有可擴展性：方便后期功能性調(diào)整善绎，接口應(yīng)具備可擴展性黔漂，但擴展性也不能盲目不切實際的幻想可能會出現(xiàn)不同的數(shù)據(jù)邏輯。
3? ：安全性
? ? ? 1）禀酱、接口安全：目前一般都是在APP客戶端和服務(wù)器通過約定的算法炬守，對傳遞的參數(shù)值進行驗證匹配。但是如果APP程序被反編譯比勉，這些約定的算法就會暴露劳较，特別是在安卓APP中，有了算法浩聋，完全就可以通過驗證模擬接口請求观蜗。或者引入jwt令牌（token）等解決方案衣洁。
? ? ? 2）墓捻、加密規(guī)范：在傳遞用戶名密碼時，應(yīng)采用規(guī)范的加密算法如MD5坊夫、RSA砖第、DES，進行數(shù)據(jù)通信請求环凿。
? ? ? 3）梧兼、https協(xié)議 ：對于敏感的api接口，使用https協(xié)議 智听，也是一種不錯的選擇羽杰，這也是一個趨勢。https是在http超文本傳輸協(xié)議加入SSL層到推，它在網(wǎng)絡(luò)間通信是加密的考赛，所以需要加密證書。https協(xié)議需要ca證書莉测，一般需要相應(yīng)的費用成本颜骤。
4：版本兼容性
? ? ? 接口不可能永遠不變，它會隨著需求的變化而做出相應(yīng)的變動捣卤。接口的變化一般會有幾種：
? ? ? 1）：數(shù)據(jù)的變化忍抽，比如增加了舊版本不支持的數(shù)據(jù)類型
? ? ? 2）：參數(shù)的變化八孝，比如新增了參數(shù)
? ? ? 3）：接口的廢棄，不再使用該接口了
為了適應(yīng)這些變化鸠项，必須得做接口版本的設(shè)計唆阿。實現(xiàn)上，一般有兩種做法：
? ? ? 1）.每個接口有各自的版本锈锤，一般為接口添加個version的參數(shù)。
? ? ? 2）.整個接口系統(tǒng)有統(tǒng)一的版本闲询，一般在URL中添加版本號久免，比如http://api.demo.com/v2。
大部分情況下會采用第一種方式扭弧，當某一個接口有變動時阎姥，在這個接口上疊加版本號，并兼容舊版本鸽捻。App的新版本開發(fā)傳參時則將傳入新版本的version呼巴。
如果整個接口系統(tǒng)的根基都發(fā)生變動的話，比如微博API御蒲，從OAuth1.0升級到OAuth2.0衣赶，整個API都進行了升級，那同樣API必須做相應(yīng)變化厚满。
有時候府瞄，一個接口的變動還會影響到其他接口，變動時需先想梳理清楚可能會涉及的接口碘箍。在做相應(yīng)的變更處理遵馆。
總之根據(jù)自身業(yè)務(wù)需求針對性的開發(fā)與用戶習慣相應(yīng)的頁面設(shè)計和App接口方案才是最理想的考慮方式方法。
