怎樣去規避一些不該屬于自己的任務而被后臺強加于自己？
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數據格式，這也是一種輕量級的數據傳輸格式，就是用一堆中括號把數據組織起來，好處：不像二進制，這種格式是人可讀的，并且比較輕巧，所以也有大量的應用場景。
（2）XML 這種比較麻煩 可讀性差
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）商品種類部分
我們來分析一下這張展示的圖片
它包含 標題和圖片
這些內容在后臺數據庫的設計中 也是一個單獨的數據庫表進行存儲，對于后臺來講查詢和取得數據是非常容易的，所以后臺只需要設計一個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和返回的數據以及在頁面的展示的情況給跟后臺看,這樣有理有據,后臺開發人員是不會說什么的,佛則,后臺會很不耐煩的,甚至罵你的可能都有,本身做后臺比較難,尤其在查詢數據,取數據,封裝數據方面都比較難處理.
