Web開發系列(五)：form, json, xml
舊石器時代：表單
很久以前的web開發是怎麼一個工作模式呢？那時候的前端不像現在的前端，那時候的前端基本上就是熟練CSS和HTML就可以了，JS要求其實 也不高，開發流程是這樣的，前端先寫好靜態頁面，然後丟給後端來套模板，那麼問題來了，如果發現頁面上的樣式要改怎麼辦？
- 方法一：前端到後端的電腦上來改
- 方法二：前端改好之後，後端重新套模板，然後各種渲染
如果前端水平高，一次性寫出無bug程式碼，那還好說，如果前端水平不行，哈哈哈哈哈哈哈哈，就等著哭吧。
那怎麼處理使用者資料呢？以前流行jQuery，一般是在button上繫結事件，使用者提交的時候，jQuery用AJAX向後端傳送一個form表單，當然 傳送之前前端可能會對資料進行校驗，但是無所謂，後端還是要校驗，後端一般拿到資料之後，除了校驗還要做型別轉換。為什麼呢？
參考這篇部落格 ，我們的form表單傳給後端的時候是沒有 型別資訊的，全都是字串，所以我們要把取出來的引數做強制轉型，此外還要檢驗引數是否存在等。
所以程式碼長得有點像這樣：
from flask import Flask, request, abort app = Flask(__name__) @app.route("/") def hello(): user_id = request.args.get("user_id") passwd = request.args.get("passwd") if not (user_id and passwd): abort(401) user_id = int(user_id) # 略略略 if __name__ == "__main__": app.run()
因此就有了一個東西，叫做表單校驗工具，是啊，誰樂意老是寫這麼多重複的校驗程式碼，說實話，之前沒用過第三方的表單校驗，都是 公司內部造的輪子，但是Python界還是有一個非常出名的表單校驗工具：ofollow,noindex" target="_blank">WTForms ， 不過說實話，我沒用過，不太好作評價。但是表單校驗工具長得都差不多：
- 定義好這個引數是否必須
- 定義好這個引數的型別
- 定義好這個引數的要求，例如範圍，長度，可否為空等
然後根據定義好的這些用響應的validators進行校驗，如果失敗就返回錯誤或者丟擲對應的異常。此外，表單校驗工具一般都會把form表單 的資料根據所定義好的型別轉換成對應的資料。
新的曙光，前後端分離
一直一直一直到了近些年，大前端時代，前後端分離這種架構慢慢流行起來。流行的原因是什麼呢？因為移動網際網路，沒人願意給前端渲染 一遍模板，又給app開發一套程式碼，麻煩得要命，所以我們只提供API，前端自己渲染資料。近年來更是有RESTFul啊這些概念，以前寫介面 那都是xml來作為傳輸格式的。
JSON，全名是JavaScript Object Notation，就是把js裡的集中基本資料型別，拿出來表示資料，其實這貨在Python裡可以很好的對映， 例如JSON的array對應Python的List，object對應dict，blablabla。一個簡單的JSON長得像這樣：
{
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
像Python這樣的動態型別語言寫這些可爽了，直接json.loads
然後開幹，但是像Go這樣的強型別靜態語言就不行了，要先定義好
JSON的結構，然後慢慢解析，雖然Go也可以強行解析成一個interface{}
，但是interface走天下也不是太好。
xml
如果你呼叫過微信的介面你就會發現，微信介面竟然還用xml。。。xml也是一種資料表現形式，長得跟html有點像，各種tag和巢狀，用來 表示複雜的關係時還可以用用，不過這年頭用xml的確實不多了。給個例子你就知道為什麼沒人願意用了，上面的JSON的例子，用xml表示 是這樣：
<!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> <glossary><title>example glossary</title> <GlossDiv><title>S</title> <GlossList> <GlossEntry ID="SGML" SortAs="SGML"> <GlossTerm>Standard Generalized Markup Language</GlossTerm> <Acronym>SGML</Acronym> <Abbrev>ISO 8879:1986</Abbrev> <GlossDef> <para>A meta-markup language, used to create markup languages such as DocBook.</para> <GlossSeeAlso OtherTerm="GML"> <GlossSeeAlso OtherTerm="XML"> </GlossDef> <GlossSee OtherTerm="markup"> </GlossEntry> </GlossList> </GlossDiv> </glossary>
emm...看到都不想碰
對比：模板渲染和前後端分離
最後我們來對比一下模板渲染和前後端分離。模板渲染有什麼好處呢？一般來說，模板渲染的效能會高一些，因為模板渲染的原理是， 渲染器把模板檔案“編譯”成對應的程式，這個程式裡的程式碼就是模板裡想表述的程式碼，然後各種字串拼接，所以模板實際上最後變成了 程式程式碼。其實你要是看到很多Java程式設計師寫模板，他們還有很多for迴圈裡put一個標籤之類的，那就是在手寫模板。
而前後端分離效能理論上應該要稍差，因為首先html下發到瀏覽器之後，瀏覽器才去獲取首頁的資料，然後渲染，當然，現在也有用 nodejs在伺服器端請求api之後渲染，其實也差不多，總之呢，前後端分離之後，前端和後端請求資料這一步是省不掉的。
既然前後端分離這麼靈活，模板渲染有啥好處？第一，容易被爬蟲抓到，第二，服務端可以丟到快取裡，這樣效能更高。而前後端分離 則恰恰相反，爬蟲不一定能抓到，很大程度上要依靠瀏覽器進行快取。但是呢，前後端分離大大的解耦了前端程式設計師和後端程式設計師， 只要約定好了API，各自更改各自的程式，互不影響。
現在我基本不寫模板渲染了，哈哈哈。
講完，收工 :)