背景
在前后端分離的開發(fā)組中窿侈，前端通常對自己代碼組織的比較細致炼幔，都會對AJAX，或者小程序API做封裝史简。而很多前端開發(fā)對后端接口要求的傳參 一頭霧水乃秀，后端開發(fā)人員對HTTP一知半解，傳參接收不到圆兵，說不清楚跺讯，互相推脫，誰誰應該改傳參方式殉农。
HTTP協(xié)議中：Content-Type刀脏，估計是非常非常多的人弄不清楚。
本質上Content-Type 要么就是?text/html要么就是?json要么就是?表單超凳。
本質上 非常簡單愈污，但總是有人搞不清楚，總是在這個上面浪費時間轮傍。
當Content-Type?為?application/json?的時候暂雹，HTTP POST請求數(shù)據(jù)必須是JSON的。
任何框架都必須遵守這個協(xié)議创夜，如果不支持杭跪，則說明框架不完善，開發(fā)者可能知識比較片面。
例子：
HTTP POST
header:
Content-Type:"application/json"
body:
{
"key1": value1,
"key2": value2
}
其中整個JSON就是 參數(shù)本身涧尿，他沒有KEY系奉，沒有名稱。key1 现斋，key2嚴格說只是屬性喜最。
當Content-Type?為?x-www-form-urlencoded?的時候，POST 的請求數(shù)據(jù)必須是表單的庄蹋。
甚至很多開發(fā)者印象中瞬内，參數(shù)就是個名字為key 值為value這種印象，這是非常膚淺的認識限书。
例子：
HTTP POST
header:
Content-Type:"x-www-form-urlencoded"
body:
key1=value1&key2=value2
何為表單參數(shù)虫蝶，就是以x-www-form-urlencoded為編碼的數(shù)據(jù)參數(shù)，其中key1 和 key2就是參數(shù)倦西。整個內容就是為 以& 分隔的參數(shù)列表能真。
例子：這里用Chrome的F12中Network類似的表示HTTP POST請求
HTTP POST
header:
Content-Type:"x-www-form-urlencoded"
body:
key1=value1
key2={"key3":value3,"key4": value4}
那這個其實也是表單！Ｈ拍７垲怼！卤档！他的形式是表單里面嵌套了一個JSON字符串蝙泼，作為其中的一個參數(shù)。
弄清楚這個了劝枣，其實根本不需要為了傳參而爭論半天汤踏。
如果參數(shù)比較單一舔腾，只做GET查詢的時候溪胶，建議直接GET。URL上面就是表單參數(shù)稳诚，和POST的表單一模一樣哗脖。
如果參數(shù)還是比較單一，但是參數(shù)值太多了采桃，很長很長的字符串懒熙，用POST是毋庸置疑的。
這個時候普办，POST?JSON和表單其實是一樣的工扎，都是在請求體里面。
如果參數(shù)是結構化的衔蹲，用POST JSON肢娘，毋容置疑呈础。
如果參數(shù)是結構化的，還需要AUTH橱健，而钞；例如帶個TOKEN，那么：
使用上面的表單2拘荡，偽JSON表單臼节，這種情況的壞處就是JAVA后端的 Model解析比較別扭，不太好建模珊皿。
使用URL + 公共參數(shù)网缝、Token，其余參數(shù)放在Body蟋定，以POST JSON傳參粉臊，沒有壞處，好處就是后端做攔截器驶兜，或者Filter的時候比較統(tǒng)一明了扼仲，不需要在Model里面涉及 公共參數(shù)。唯一的壞處就是抄淑，前端同學可能懶得弄屠凶。
前端封裝的框架，必須支持 公共參數(shù)追加到URL肆资，并且可以以JSON傳參乳规。
后端就可以依據(jù)以上的情況映九，靈活使用參數(shù)組織方式了，處理業(yè)務的代碼專心接受參數(shù)冤馏，
攔截器直接通過URL獲取公共參數(shù)和Token监署，來做一些版本控制颤专，身份認證等功能。
