APP後端資料介面注意事項
不但如此，越來越多的傳統應用、網站也都開始製作自己的移動APP，也就是我們常說的IOS客戶端、android客戶端。
這彷彿又回到了多年前的CS架構，那時候我們用VB、VC、Delphi在Windows平臺上快速開發各種應用程式。
不同的是，如今的移動端APP基本上都是聯網從伺服器端獲取各種資料，客戶端只是一個簡單的表現層的工具。
不僅僅是移動APP，包括面向服務的SOA架構，都需要制定一套統一、規範的介面，
那麼，做這樣的後端介面需要注意哪些問題呢？
1、跨平臺性
所謂跨平臺是指我們的介面要能夠支援不同的終端，比如android、ios、windowsphone以及桌面軟體、網站等，
一套介面，支援多端，就像當年Java的口號一樣“Write Once,Run Anywhere”。
當然從本質上講，伺服器端的介面跟終端是沒有太大關係的，只是介面應該考慮到不同端的接入成本，
採用通用的解決方案，比如通訊協議就採用最常用的HTTP協議，如果是即時通訊，可以採用開放的XMPP協議，
做遊戲的可以採用可靠的TCP協議，除非TCP不夠用了，再採用定製的UDP協議。
資料交換採用xml或者json格式等等。
總之，要達到的目標就是讓不同的端能夠很方便的使用你的介面。
2、良好的響應速度
如果要用一個指標來衡量介面的效能的話，那麼我想最重要的就是響應速度了。
介面應該以最快的速度將資料返回給請求者。
試想，當我們開啟一個頁面，如果“努力載入中”之類的提示超過三五秒鐘的話，
我們肯定會變得不耐煩，移動app本來大部分就是使用者在碎片化時間來使用的，
在有限的時間內，使用者恨不得獲得的資訊越多越好，即使你的app介面設計的再好，使用者也不會買賬。
提高響應速度又是個老生常談的問題，大體上應該按照以下步驟來做：
初期，以功能為主，要保證功能完整，滿足業務需求，這階段可以使用動態的語言，比如java、php、asp.net等，
配合設計良好的資料庫結構和索引，能滿足一定的需求；
其次，隨著使用者的增多，可以考慮一些快取方案，快取是解決效能問題的萬金油，通常能起到立竿見影的效果。
最常用的靜態檔案快取，memcached記憶體快取等。
然後，單臺機器的吞吐率不行了，通過負載均衡多加幾臺機器就行了。七八臺機器，支援每天千萬級的介面呼叫是可行的。
或者，直接採用CDN的解決方案，將絕大多數的靜態資源交給CDN去處理。
總之，要達到的目標就是快，一個頁面，秒開最好，超過三秒就需要找找原因了。
3、介面要為移動客戶端考慮
介面不僅僅是提供資料和功能就完事了，更應該充分考慮移動端的特性，為移動端提供更加方便、快捷的介面。
比如，在移動端裡，下拉重新整理和上拉載入更多是很常見的功能，如果介面仍然按照傳統的web思路，
只提供按頁讀取的話，就會造成移動端的額外的資料請求和計算。 這時，介面就應該針對這兩種型別的操作提供額外的支援。
再比如，對於一個新聞閱讀類的app來說，最新的新聞列表裡的文章，特別是前幾條，使用者很容易點選進去看，
而後面的老的文章列表，一來使用者下滑載入好幾頁的情況較少，二來過時的新聞使用者也很少點。
如果，介面在返回新聞列表時，對於最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的內容）資訊一起傳給客戶端，
這樣，使用者在開啟新聞詳情頁的時候，就不用再從伺服器端獲取了，自然可以做到秒開。
比如訪問第一頁時，介面可以返回文章內容，如下所示 ，content=1表示載入文章內容
newslist?page=1&pagesize=20&content=1
其他頁時，newslist?page=5&pagesize=20&content=0 ,不用載入文章內容。
當然，客戶端要跟介面做好配合，搭配好，才能最大化的提高效能。
比如，移動端都有左右滑動來看上一篇、下一篇文章或者圖片的功能，
如果，當用戶請求某篇文章的時候，伺服器端順便也把下一篇文章的內容返回回來了，
那麼當用戶看下一篇的時候，是不是就很快了呢。
當然這種preload的方案也不能濫用，如果預載入資料的命中率較低的話，也不行，白白浪費了很多的流量。
4、考慮移動端的網路情況和耗電量
如果讓我們說出哪類app比較好，可能還不大好說，但是如果讓我們說出哪些app很差，
我們肯定會說出那些 體積很大、佔用記憶體多、介面很卡、費電的app不好。
對於移動APP開發者來說， 網路流量和電池電量是不得不考慮的問題。
不過，您也許會說，這些跟介面沒啥關係吧，伺服器端的介面還能管得了客戶端的網路流量和電量？
對於網路情況，介面應該具備為不同的網路提供不同的內容的能力，
通常，移動端的上網方式無非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，
設想一下，如果使用者在流量需要花錢的情況下，你的app給使用者展示了視訊、音訊、大量的圖片而沒有通知使用者的情況下，
使用者會怎麼想，畢竟國內的流量費用還是很貴的。
還以上面的新聞列表介面為例，如果我們能夠知道使用者的網路情況，只有在wifi的情況下才給使用者傳輸封面圖、縮圖之類的，
是不是可以幫使用者節省很多流量呢。
newslist?page=1&pagesize=20&content=1&network=wifi
對於電量，首先我們要弄清楚，app的哪些方面會消耗電量？
比如app有大量的計算、有很炫的視覺畫面都會消耗電量， 另外，不斷的行動網路連結也會消耗大量的電量，
我們都知道行動網路是通過無線電波來通訊的，那麼發射裝置就需要消耗一定的電量來發射和接收無線訊號。
特別的是，頻繁的連結會不斷的切換網路裝置與移動基站之間連線狀態，這都會消耗一部分電量。
所以，對於介面而言，儘量用少的連結傳輸多的資料，
比如，對於關於我們、版本更新以及一些系統配置資訊，完全可以通過一次連結全部返回給客戶端。
5、通用的資料交換格式
目前，對於介面和客戶端的資料交換格式，基本上就是兩種，xml和json，而現在使用json的應該佔大多數。
交換的資料包括兩種，一種是客戶端請求伺服器端介面時傳遞的一些引數，一種是伺服器端返回給客戶端的資料。
對於客戶端的請求引數，現在也越來越多的介面要求採用json的格式，而不是以往最常見的key_value對了。
比如，介面需要username和password兩個引數
key_value pair的方式是：
username=hutuseng&password=hutusengpwd
然後通過GET或者POST方式傳送。
而通過json方式交換資料的話，格式如下，直接POST到伺服器端。
{
'username':'hutuseng',
'password':'hutusengpwd'
}
對於伺服器端返回的json資料格式，需要注意兩個問題：
一是漢字編碼問題，因為json（javascript）內部支援Unicode編碼，會將漢字等轉換成unicode編碼儲存，
所以在返回結果中，對於中文，可以直接輸出中文，也可以輸出中文的unicode編碼，
json解析器都會很好的解析。
比如下面兩種方式都是可以的。
{"code":"208","data":"\u53c2\u6570\u4e0d\u5b8c\u6574"}
{
"code": "208",
"data": "引數不完整"
}
二是欄位的資料型別，特別是數字型別的，json中儘量轉成數字格式，
比如
{
'userid':128
}
不要寫成
{
'userid':'128'
}
6、介面統計功能
在做PC端網站的時候，我們都會給我們的網站加上個統計功能，要麼自己寫統計系統，要麼使用第三方的比如GA、百度等。
移動端介面API則需要我們自己實現統計功能，
這時就需要我們儘可能多的收集客戶端的資訊，除了傳統的IP、User-Agent之外，還應該收集一些移動相關的資訊，
比如
手機作業系統，是android還是ios，都是什麼版本，
使用者使用的網路狀況，是2G、3G、4G還是WIFI
客戶端APP是什麼版本資訊。
這樣，有助於我們更好的瞭解我們使用者的使用情況。
7、客戶端與服務端的肥瘦平衡
在以前C/S、B/S架構時，我們就已多次討論過這個問題，客戶端是瘦點好還是肥點好，當然也沒有固定答案，需要自己根據實際情況去做權衡。
但是，在移動開發中，由於客戶端的修改會很費時費力，特別是IOS應用還要經過Apple稽核，
另外，當前IOS開發人員、Android開發人員的人工成本普遍較高，人才緊缺，
基於這兩點，能在伺服器端實現的功能就不要放在客戶端，畢竟伺服器端程式的修改要比客戶端方便、靈活、快捷的多。
8、隱式使用者與顯式使用者
顯式使用者和隱式使用者，我不知道這兩個詞用的是否確切。
顯式使用者指的是，APP程式中有使用者系統，一個username、password正確的合法使用者，稱之為顯式的使用者，
通常顯式使用者都需要註冊，登入以後能完成一些個人相關的操作。
隱式使用者指的是，APP程式本身就沒有使用者系統，或者一個在沒有登入的情況下，使用我們APP的使用者。
在這種情況下，可以通過客戶端生成的UDID來標識一個使用者。
有了使用者資訊，我們就能夠了解不同使用者的使用習慣，而不僅僅是全體使用者的一個整體的統計資訊，
有了這些個體的資訊之後，就可以做一些使用者分群、個性化推薦之類的事情。
9、安全問題
網路安全已經從桌面網際網路轉到了移動網際網路，從客戶端蔓延到了介面API中。
傳統固若金湯的網站，很可能因為介面的一點疏忽而遭受入侵。現在，在很多白帽子或者黑客的入侵思路中，
先看看移動端介面是否存在漏洞，再看網站是否有漏洞。
客戶端APP與介面的通訊很容易被得到，只要在中間路由上嗅探一下就行，whireshark、tcpdump這類工具使得這項工作變得簡單無比。
所以，介面的安全工作不能馬虎，暴力破解啊、SQL Injection啊、偽造請求和資料啊、重複提交啊也要考慮到,
如果資料特別敏感，可以考慮採用SSL/TLS等加密傳輸，或者客戶端、伺服器端約定一個加密演算法和金鑰，對來往傳輸的資料進行加密、解密
如果不採用RESTful API，可以採用基於WSDL和SOAP的Web Service的安全措施。
10、良好的介面說明文件和測試程式
介面文件有時候是專案初期就定下來的，前後端開發人員按照介面規範開發，
有的是介面開發完成後寫的。
介面文件要清晰、明瞭，包含多少個介面，每個介面的地址、引數、請求方式、資料交換格式、返回值等都要寫清楚。
介面測試程式，有條件的話，也可以提供，方便前後端的除錯。
隨著業務的變化，客戶端APP和伺服器端API都會發生變化，增加新的功能，修改已有的功能，
增加功能還好說， 如果是介面需要修改，那麼就面臨著同一個介面要同時為不同版本的客戶端服務的問題。
因此，伺服器端介面也要做好相應的版本維護。
相關推薦
APP後端資料介面注意事項
2014年，移動APP的熱度絲毫沒有減退，並沒有像桌面軟體被WEB網站那樣所取代， 不但如此，越來越多的傳統應用、網站也都開始製作自己的移動APP，也就是我們常說的IOS客戶端、android客戶端。 這彷彿又回到了多年前的CS架構，那時候我們用VB、VC、Delphi在Windows平臺上快速開發各種應用
layui-tree控制元件的使用 和 後端資料介面通用化
<?php include('./lay.php');?> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=de
Android請求獲取Java後端資料,登入介面例子
最近做了個Android請求獲取Java後端資料的例子，簡單實現了一下。先上個登入介面圖： 主要實現：java後端的程式碼 + Android的程式碼1、java後端（1）、先創個User類import net.sf.json.JSONObject; public cla
PHP開發APP介面注意事項
一、雙方統一介面開發文件 為了提升開發效率及溝通方便，需要建立規範的開發文件。 一般保護介面的功能或頁面、介面地址、介面引數、介面返回值等說明。 參考文件格式： 二、注意以下 分版本
從零開發一款APP 三、Java Web後端登陸介面的設計
一、邏輯設計： 在設計好並做完註冊介面後，我們就需要做登陸介面了，其實登陸介面非常的簡單，去資料庫中驗證其使用者名稱和密碼（當然，傳輸的資料要進行加密，我們會在後面統一加密方法），如果正確，那麼要傳回其相應的token，使用者得到其token之後，以後就可以使用這個tok
app後端設計-資料增量更新
使用資料的app本地儲存，能減少網路的流量，同時極大提高了使用者的體驗（想想，很多資料都能在app本地獲取，顯示的速度當然快）。使用了本地儲存後，需要考慮的是資料的增量更新方案。 什麼是資料的增量更新？假設，使用者A的首頁在資料表中是有40條資料，id1-40，app每次獲取10條資料。第一
1.APP後端開發系列：登陸系統設計中的注意問題
想寫這個系列很久了，因為之前做這個東西花費了大量的精力，有必要分享出來與大家共享。以前也寫了一些關於 APP後端開發的系列文章 由於當初功力不夠，很多問題描述不清楚或者解決方案過於複雜、不嚴謹等。 這一次查了很多資料，問了很多相關人士。準備再結合自己實際工
模仿J2EE的session機制的App後端會話信息管理
序列化 相關 || redis 字節 param div 模仿 remove 此文章只將思想，不提供具體完整實現（博主太懶，懶得整理），有疑問或想了解的可以私信或評論 背景 在傳統的java web 中小型項目中，一般使用session暫存會話信息，比如登錄者的身份信息
app後端api設計【轉】
不用 ray 版本更新 array nvl 動態生成 出錯 命名 test 博客：https://blog.csdn.net/newjueqi/article/details/44037011 app和後端的交互，一般都是通過後端提供的api實現。api的設計，估計很多
Odoo作為App後端時如何調試App
技術分享 Edito 管理系 cno onf span edi 後臺系統 pre 轉載請註明原文地址：https://www.cnblogs.com/cnodoo/p/9307340.html 一：Odoo可以作為app後臺+後臺管理系統使用 Odoo作為一個可供
APP後端搭建整理
常見的APP後端搭建 語言有 Java，PHP，Python,下面可以簡單瞭解一下 Java： https://blog.csdn.net/a_running_wolf/article/category/6188707 http://keeganlee.me/post/pract
一次有趣的ant-design與後端資料互動的使用
最近有個需求是新聞時間排序與點選量排序，資料庫中儲存的新聞是按照時間順序排序的，從後臺資料中取出資料，在前端進行頁面展示即可。 我用到了ant-design中的Tabs切換頁,樣式大概如下圖。 其實這個專案裡面最令我欣喜的是reducer中介軟體的封裝，無需通過fetch請求資料這些，而是使用另外的封裝中介
mysql資料型別/注意事項/int(20)混淆
int(20), bigint(20)括號裡的內容指的是顯示時填充0的個數，而不是位元組或空間限制，不同於char(20)或varchar(20)的意義： https://stackoverflow.com/questions/3135804/types-in-mysql-bigint20-vs-int20
Spring MVC利用Hibernate Validator實現後端資料校驗
吐槽一下，網上坑好多啊！不過採坑才能學習，寫bug能力-1。 JSR 303、JSR 349與Bean Validator 籠統來說，就是Java規定了一套關於驗證器的API，
layui 富文字 圖片上傳 後端PHP介面
layui 富文字 圖片上傳 後端PHP介面 html <!DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/css" href="/static/layui/
Atitit 面試技術點最小化問題法總結 目錄 1. Web 前端 1 1.1. Jq 常用操作哪些？？ 1 1.2. 查詢後如何繫結後端資料到表格 2 1.3. 提交後怎麼接受表單資料 2 2.
Atitit 面試技術點最小化問題法總結 目錄 1. Web 前端 1 1.1. Jq 常用操作哪些？？ 1 1.2. 查詢後如何繫結後端資料到表格 2 1.3. 提交後怎麼接受表單資料 2 2. Mvc Springmvc 2 2.1
html用ajax請求伺服器後端java介面跨域問題解決
在html頁面加入以下程式碼： <meta http-equiv="Access-Control-Allow-Origin" content="*"> 在java後端程式碼的介面中加入 response.setHeader("Access-
Easy-mock你再也不用等後端的介面了
引言 今天我們來聊聊Mock，隨著網際網路發展，這兩年前後端分離的開發模式興起，Mock也從以住的幕後走上了檯面，讓更多的人而得知，以前傳統的開發方式Mock大多侷限在後端人員接觸較多一些。 Mock已經是老生常談了，網上一搜索就很多，各位前輩們都講的很到位，但今天我只講它——easy-mo
【SSM】【4】前端後端資料流轉
前後端資料流轉圖： 業務流轉圖 前端控制器接受使用者請求響應 doJsonRequest("/ursuser/login.json", json, function (data) { if (getUrlParam
SQL Server 中資料查詢注意事項
1.查詢語句不用區分大小寫，而且即使每張表的表名或者列名出現大寫字母，在寫查詢語句的時候也不用區分大小寫，查詢結果保持一致，所以查詢語句小寫即可。 2.在寫查詢語句的時候列名不需要帶單引號，數值型的字串不用帶引號，需要帶引號的是字元型和漢字型的字串。 3.如果既要用到group by子句，也要用到orde