背景

在前後端分離的開發組中，前端通常對自己程式碼組織的比較細緻，都會對AJAX，或者小程式API做封裝。而很多前端開發對後端介面要求的傳參 一頭霧水，後端開發人員對HTTP一知半解，傳參接收不到，說不清楚，互相推脫，誰誰應該改傳參方式。

HTTP協議中：Content-Type，估計是非常非常多的人弄不清楚。

本質上Content-Type 要麼就是 text/html要麼就是 json要麼就是 表單。

本質上 非常簡單，但總是有人搞不清楚，總是在這個上面浪費時間。

JSON

當Content-Type 為 application/json 的時候，HTTP POST請求資料必須是JSON的。
任何框架都必須遵守這個協議，如果不支援，則說明框架不完善，開發者可能知識比較片面。

例子：

HTTP POST

header:
Content-Type: "application/json"

body:
{
    "key1": value1,
    "key2": value2
}

其中整個JSON就是 引數本身，他沒有KEY，沒有名稱。key1 ，key2嚴格說只是屬性。

表單

當Content-Type 為 x-www-form-urlencoded 的時候，POST 的請求資料必須是表單的。
甚至很多開發者印象中，引數就是個名字為key 值為value這種印象，這是非常膚淺的認識。

例子：

HTTP POST

header:
Content-Type: "x-www-form-urlencoded"
 


body:
key1=value1&key2=value2

何為表單引數，就是以x-www-form-urlencoded為編碼的資料引數，其中key1 和 key2就是引數。整個內容就是為 以& 分隔的引數列表。

表單2

例子：這裡用Chrome的F12中Network類似的表示HTTP POST請求

HTTP POST

header:
Content-Type: "x-www-form-urlencoded"

body:
key1=value1
key2={"key3":value3, "key4": value4}

那這個其實也是表單！！！！！他的形式是表單裡面嵌套了一個JSON字串，作為其中的一個引數

弄清楚這個了，其實根本不需要為了傳參而爭論半天。

什麼情況應該用什麼傳參？

如果引數比較單一，只做GET查詢的時候，建議直接GET。URL上面就是表單引數，和POST的表單一模一樣。

如果引數還是比較單一，但是引數值太多了，很長很長的字串，用POST是毋庸置疑的。
這個時候，POST JSON和表單其實是一樣的，都是在請求體裡面。

如果引數是結構化的，用POST JSON，毋容置疑。

如果引數是結構化的，還需要AUTH，；例如帶個TOKEN，那麼：

• 使用上面的表單2，偽JSON表單，這種情況的壞處就是JAVA後端的 Model解析比較彆扭，不太好建模。
• 使用URL + 公共引數、Token，其餘引數放在Body，以POST JSON傳參，沒有壞處，好處就是後端做攔截器，或者Filter的時候比較統一明瞭，不需要在Model裡面涉及 公共引數。唯一的壞處就是，前端同學可能懶得弄。

小程式前端 與後端配合開發的經驗

前端封裝的框架，必須支援 公共引數追加到URL，並且可以以JSON傳參。
後端就可以依據以上的情況，靈活使用引數組織方式了，處理業務的程式碼專心接受引數，
攔截器直接通過URL獲取公共引數和Token，來做一些版本控制，身份認證等功能。