首先我們知道http請求及服務端響應中傳輸的所有資料都是字串.
在django中,當我們訪問乙個的url時,會通過路由匹配進入相應的html網頁中.
django的請求生命週期是指當使用者在瀏覽器上輸入url到使用者看到網頁的這個時間段內,django後台所發生的事情
而django的生命週期內到底發生了什麼呢??
1. 當使用者在瀏覽器中輸入url時,瀏覽器會生成請求頭和請求體發給服務端
請求頭和請求體中會包含瀏覽器的動作(action),這個動作通常為get或者post,體現在url之中.
2. url經過django中的wsgi,再經過django的中介軟體,最後url到過路由對映表,在路由中一條一條進行匹配,
一旦其中一條匹配成功就執行對應的檢視函式,後面的路由就不再繼續匹配了.
3. 檢視函式根據客戶端的請求查詢相應的資料.返回給django,然後django把客戶端想要的資料做為乙個字串返回給客戶端.
4. 客戶端瀏覽器接收到返回的資料,經過渲染後顯示給使用者.
檢視函式根據客戶端的請求查詢相應的資料後.如果同時有多個客戶端同時傳送不同的url到服務端請求資料
服務端查詢到資料後,怎麼知道要把哪些資料返回給哪個客戶端呢??
因此客戶端發到服務端的url中還必須要包含所要請求的資料資訊等內容.
例如,這個url中,
客戶端通過get請求向服務端傳送的nid=user
的請求,服務端可以通過request.get.get("nid")
的方式取得nid資料
客戶端還可以通過post的方式向服務端請求資料.
當客戶端以post的方式向服務端請求資料的時候,請求的資料報含在請求體裡,這時服務端就使用request.post的方式取得客戶端想要取得的資料
需要注意的是,request.post是把請求體的資料轉換乙個字典,請求體中的資料預設是以字串的形式存在的.
乙個url對應乙個檢視函式,這個模式叫做fbv(function base views
)
除了fbv之處,django中還有另外一種模式叫做cbv(class base views
),即乙個url對應乙個類
例子:使用cbv模式來請求網頁
路由資訊:
urlpatterns = [
url(r'^fbv/',views.fbv),
url(r'^cbv/',views.cbv.as_view()),
]
檢視函式配置:
cbv.html網頁的內容:
啟動專案,在瀏覽器中輸入
,回車,得到的網頁如下:
在input框中輸入"hello",後回車,得到的網頁如下:
使用fbv的模式,在url匹配成功之後,會直接執行對應的檢視函式.
而如果使用cbv模式,在url匹配成功之後,會找到檢視函式中對應的類,然後這個類回到請求頭中找到對應的request method
.
如果是客戶端以post的方式提交請求,就執行類中的post方法;
如果是客戶端以get的方式提交請求,就執行類中的get方法
然後查詢使用者發過來的url,然後在類中執行對應的方法查詢生成使用者需要的資料.
使用者傳送url請求,django會依次遍歷路由對映表中的所有記錄,一旦路由對映表其中的一條匹配成功了,
就執行檢視函式中對應的函式名,這是fbv的執行流程
當服務端使用cbv模式的時候,使用者發給服務端的請求包含url和method,這兩個資訊都是字串型別
服務端通過路由對映表匹配成功後會自動去找dispatch方法,然後django會通過dispatch反射的方式找到類中對應的方法並執行
類中的方法執行完畢之後,會把客戶端想要的資料返回給dispatch方法,由dispatch方法把資料返回經客戶端
例子,把上面的例子中的檢視函式修改成如下:
列印結果:
dispatch......
需要注意的是:
以get方式請求資料時,請求頭里有資訊,請求體裡沒有資料
以post請求資料時,請求頭和請求體裡都有資料.
http提交資料的方式有"post"
,"get"
,"put"
,"patch"
,"delete"
,"head"
,"options"
,"trace"
.
提交資料的時候,服務端依據method的不同會觸發不同的檢視函式.
對於from表單來說,提交資料只有get和post兩種方法
另外的方法可以通過ajax方法來提交
服務端根據個人請求資訊的不同來運算元據庫,可以使用原生的sql語句,也可以使用django的orm語句.
django從資料庫中查詢處理完使用者想要的資料,將結果返回給使用者.
從django中返回的響應內容包含響應頭和響應體
在django中,有的時候乙個檢視函式,執行完成後會使用httpresponse來返回乙個字串給客戶端.
這個字串只是響應體的部分,返回給客戶端的響應頭的部分應該怎麼設定呢???
為返回給客戶端的資訊加乙個響應頭:
修改上面例子的檢視函式為如下:
列印的資訊:
res: 200, "text/html; charset=utf-8">
request.cookie:
django請求生命週期
wsgi,他就是socket服務端,用於接收使用者請求並將請求進行初次封裝,然後將請求交給web框架 flask django 框架對wsgi封裝好的請求再次封裝,封裝成request 中介軟體,幫助我們對請求進行校驗或在請求物件中新增其他相關資料,例如 csrf request.session 路...
Django請求生命週期
流程 橙色箭頭 瀏覽器向後端傳送請求,先到web服務閘道器介面,裡面有乙個wsgiref模組,該模組是django自帶的,自身能夠承受的併發量非常小,大概只有一千左右,上線之後通常會謊稱uwsgi,而且在他前面還會加上nginx做反向 來提高 的併發量。接下來就走到了urls.py,路由與檢視函式分...
Django 請求生命週期
django 請求生命週期 概念 使用者在瀏覽器上輸入url連線到看都頁面的時間內,django後台發生的事。第一步 瀏覽器發起請求 第二步 wsgi建立socket服務端,接收請求 httprequest 第三步 中介軟體處理請求 第四步 url路由,根據當前請求的url找到檢視函式 第五步 vi...