iOS前端與後台互動技術實現及技術細節

標籤：

摘要

今天由我給大家進行一場技術分享,分享的主題也是大家還沒有工作或者才去工作不久或者是正處於試用期的同學非常關心的一個問題,就是我們做iOS,HTML5,安卓等前端開發的如何跟我們的公司後台進行互動.
面臨後台我們應該說些什麼?
應該怎麼去規避一些不該屬於自己的任務而被後台強加於自己?等等問題.

目錄

    1.前端請求資料URL的誰來寫?    2.介面文檔主要由誰來寫?    3.前端開發與後台互動的資料格式主要是什麼?    4.前端開發的後台互動原理？    5.前端請求參數的形式    6.前台應該告知後台哪些有效資訊,後台才能返回前端想的資料的呢?    7.我們應該怎麼把頁面這些資訊有效傳達給後台呢,以及後台是如何擷取到資料的呢?    8.前端應該如何規避一些本不屬於自己做的一些功能需求或任務呢?    9. 當前端在調用資料介面時,發現有些資料不是我們想要的,那麼前端應該怎麼辦呢或者怎麼跟後台講呢?

下面來給大家進行詳細的解釋.

1.前端請求資料的URL由誰來寫?

  在開發中,URL主要是由後台來寫的,寫好了給前端開發人員.

如果後台在查詢資料,需要藉助查詢條件才能查詢到前端需要的資料時,這時後台會要求前端提供相關的查詢參數,例如:

  select "產品圖片","優惠[買2送花茶]","產品名稱","商品價格","是否包郵" from tb_goodList where time = “傳遞過來的參數"  如果 沒有後面的查詢條件,就會查詢到所有的時間的資料,前端則需要的是某一天的資料,這時前端就需要把時間當做參數傳遞給後台,後台根據這個參數再進行資料查詢.返回前端頁面需要的資料.例如:  http://www.hehe168.com/goodList.php?time="2016-05-12 00:00:00"

2.介面文檔主要由誰來寫?

介面文檔也是主要由後台開發人員來寫的,因為直接跟資料打交道的就是後台,後台是最清楚,資料庫裡面有什麼資料,能返回什麼資料.前端開發只是資料的被動接受者.所以介面文檔也主要是由後台來完成的,前端只是介面文檔的使用者,使用過程中,發現返回的資料不對,則需要跟後台進行商量,由後台來修改.切記 前端不要隨意更改介面文檔,除非在取得後台開發人員的同意的情況下.

總的來講,介面文檔主要由後台來設計,修改,前端開發人員起到了輔助的作用.

3.前端開發與後台互動的資料格式主要是什麼?

1) 另一種是 JSON（JavaScriptObject Notation），這也是一種輕量級的資料轉送格式，就是用一堆中括弧把資料群組織起來，
好處:不像二進位，這種格式是人可讀的，並且比較輕巧，所以也有大量的應用情境。採用json資料格式進行傳送.

2) XML

但是我們項目中用的最多的就是JSON資料格式,它的一般形式:
{“flag”:”001”,”content”:{}}

4.前端開發的後台互動原理？

在項目的時候，我們前後端會大概說一下介面地址，前端請求的參數，後端返回的參數，然後大家就開始寫，寫的差不多的時候，大家調一下介面看一下返回的資料，沒問題就可以了。

5.前端請求參數的形式

GET和POST是HTTPS的兩個常用方法。
GET - 從指定的伺服器中擷取資料
POST - 提交資料給指定的伺服器處理

GET方法特點：
使用GET方法時，查詢字串（索引值對）被附加在URL地址後面一起發送到伺服器：
/test/demo_form.jsp?name1=value1&name2=value2
特點：
GET請求能夠被緩衝
GET請求會儲存在瀏覽器的瀏覽記錄中
以GET請求的URL能夠儲存為瀏覽器書籤
GET請求有長度限制
GET請求主要用以擷取資料

POST方法：
使用POST方法時，查詢字串在POST資訊中單獨存在，和HTTP請求一起發送到伺服器：
POST /test/demo_form.jsp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
特點：
POST請求不能被緩衝下來
POST請求不會儲存在瀏覽器瀏覽記錄中
以POST請求的URL無法儲存為瀏覽器書籤
POST請求沒有長度限制

6.前台應該告知後台哪些有效資訊,後台才能返回前端想的資料的呢?

    首先,前端要先學會對一個頁面展示的資料進行有效分析,把需要的資料都記下來,然後告知後台.大家看到還是感到很迷惑,我來舉一個例子給大家進行詳細的解釋.看圖片:

以這個圖為例:我們可以把這個頁面劃分為三個部分如所示:

1) 輪播圖部分2) 商品種類部分3) 每日推薦部分

接下來我們會對這三部分進行詳細的解釋.請大家繼續往下看.
7.那麼我們應該怎麼把這些頁面資訊有效傳達給後台以及後台如何擷取資料的?

1) 輪播圖部分

前端部分:我頁面需要今天產品的最新圖片地址,URL中的參數主要是根據後台需要,如果後台需要前端傳遞一個時間,才能夠查詢到具體的圖片資訊,那麼前端在資料請求時請求參數就應該包含時間的參數,例如:

  URL:http://www.hehe168.com/GetPicture.php  或者http://www.hehe168.com/GetPicture.php?time="2016-05-12 00:00:00"

後台部分:就會去資料庫裡面去尋找相應的資料表中的例如輪播圖表,查詢條件就是前端傳遞過來的URL參數time例如:

       select “輪播圖片” from tb_picture where time = "2016-05-12 00:00:00"

2) 商品種類部分

我們來分析一下這張展示的圖片.

他包含哪些內容呢,是不是包含:

1)標題圖片2)標題

這些內容在後台資料庫表的設計中 也是一個單獨的資料庫表進行儲存,對於後台來講查詢和取得資料是非常容易的.所以後台只需要設計個URL給前端就可以了,如果需要什麼輔助參數,後台會直接向前端要求的.例如:
URL形式:

URL:http://www.hehe168.com/variety.php或者http://www.hehe168.com/variety.php?time="2016-05-12 00:00:00"

3) 每日推薦部分

:

我們看下上面圖它包含哪些內容:

1)產品圖片2)優惠[買2送花茶]  3)產品名稱 4)商品價格5)是否包郵

前端把這些資訊告知後台,後台看到這些資訊後,會去相對應的資料庫去查詢,如果這些資料後台很容易擷取到,會直接給個URL給前端.否則就需要前端通過URL來傳遞一些參數.
URL形式:

URL:http://www.hehe168.com/goodList.php或者http://www.hehe168.com/goodList.php?time="2016-05-12 00:00:00&clases=""

所以總的來講:所有前端請求的URL後面的參數,都是輔助後台資料查詢的.如果不需要參數,那麼後台就會直接給個URL給前端.

好這個頁面分析完了,大家應該有個初步認識了吧.接著往下講.

8.前端應該如何規避一些本不屬於自己做的一些任務或功能需求呢?

    在與後台打交道中,我們經常遇到這種情況,有時候明明後台來處理某個事件很簡單,後台非要你來做,這時候我們應該懂得去回絕他.

應該怎麼去回拒它呢?

    這可能對於之前沒做過項目,或者沒與後台打交道的人來講非常頭痛的事,這就需要我們對一個需求,一個任務的要有清晰認識了,如果對任務含糊不清,自己都沒搞明白,你只能受後台擺布了.最後也會因為任務沒有完成而備受責難了.在這裡就不給大家舉例子了.

面臨這樣的問題,我們應該如何去做呢?

 在這裡給大家一些建議,也就是在與後台打交道時,不要輕易的承諾,對很多自己熟悉的需求或功能點,自己可以立刻答應下來,對那些模糊不清,記下來,回去百度,看看具體原理是什麼,是不是該前端這邊去實現或者實現起來非常困難,那麼想想後台是否做起來很方面,去跟後台商量.

9. 當前端在調用資料介面時,發現有些資料不是我們想要的,那麼前端應該怎麼辦呢或者怎麼跟後台講呢?

  解決辦法:1,首先要把請求的URL和返回的資料以及在頁面的展示的情況給跟後台看,這樣有理有據,後台開發人員是不會說什麼的,佛則,後台會很不耐煩的,甚至罵你的可能都有,本身做後台比較難,尤其在查詢資料,取資料,封裝資料方面都比較難處理.

總結

與後台互動大致就是這些問題,大家都應該有所瞭解了吧.
部落格地址:http://blog.csdn.net/baihuaxiu123

iOS前端與後台互動技術實現及技術細節