1111111

第一講——Django之知識帶入 2019-09-24
字數統計: 6.1k 字 閱讀時長: 21min
很簡潔的一個學習dj的網站：https://code.ziqiangxuetang.com/django/django-admin.html

HTTP協議相關
HTTP協議簡介
HTTP，超文本傳輸協議（HyperText Transfer Protocol)是互聯網上應用最爲普遍的 一種網絡協議。全部的WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法，HTTP是萬維網的數據通訊的基礎。如今應用最普遍的是HTTP1.1版本

HTTP工做流程
HTTP是一個客戶端終端（用戶）和服務器端（網站）請求和應答的標準（TCP）。經過使用網頁瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個HTTP請求到服務器上指定端口（默認端口爲80）。咱們稱這個客戶端爲用戶代理程序（user agent）。應答的服務器上存儲着一些資源，好比HTML文件和圖像。咱們稱這個應答服務器爲源服務器（origin server）。在用戶代理和源服務器中間可能存在多個「中間層」，好比代理服務器、網關或者隧道（tunnel）。

注意：

這個協議在TCP/IP協議棧的應用層，所以咱們無需操心HTTP是如何傳輸的，只須要關心咱們傳輸的內容是否正確的被接收端識別。
HTTP是基於TCP實現的，簡單的說就是TCP協議負責可靠的內容傳輸，HTTP協議負責識別內容，二者不在一個層面上。
HTTP無狀態的含義是每一次的內容解析是沒有關聯的。TCP有狀態鏈接是指兩端在鏈接過程的。
HTTP包含兩種報文信息：請求報文和響應報文。
HTTP的工做原理
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

客戶端鏈接到Web服務器
一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。例如，http://www.luffycity.com。
發送HTTP請求
經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
釋放鏈接TCP鏈接
若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;
客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。
例如：在瀏覽器地址欄鍵入URL，按下回車以後會經歷如下流程：

瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器創建TCP鏈接;
瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文做爲 TCP 三次握手的第三個報文的數據發送給服務器;
服務器對瀏覽器請求做出響應，並把對應的 html 文本發送給瀏覽器;
釋放 TCP鏈接;
瀏覽器將該 html 文本並顯示內容;
HTTP的特色　
基於 請求-響應 的模式：HTTP協議規定,請求從客戶端發出,最後服務器端響應該請求並 返回。
無狀態保存：HTTP協議 自身不對請求和響應之間的通訊狀態進行保存。也就是說在HTTP這個 級別,協議對於發送過的請求或響應都不作持久化處理，每次到來的請求都是一個新請求。
無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。
HTTP請求方法
根據HTTP標準，HTTP請求可使用多種請求方法。

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

注： 有請求體(請求體有數據)確定是post提交(表單method是post)

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

序號 方法 描述
1 GET 請求指定的頁面信息，並返回實體主體。使用GET方法應該只用在讀取數據。
2 HEAD 相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3 POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改，或兩者皆有。
4 PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。
5 DELETE 請求服務器刪除Request-URI所標識的資源。
6 CONNECT HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7 OPTIONS 容許客戶端查看服務器的性能。
8 TRACE 回顯服務器收到的請求，主要用於測試或診斷。
對比GET和POST請求：

GET提交的數據會放在URL以後，也就是請求行裏面，以?分割URL和傳輸數據，參數之間以&相連，如EditBook?name=test1&id=123456.（請求頭裏面那個content-type作的這種參數形式，後面講）；POST方法是把提交的數據放在HTTP包的請求體中。
GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。
HTTP狀態碼
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。

下面是常見的HTTP狀態碼：

200 - 請求成功
301 - 資源（網頁等）被永久轉移到其它URL
404 - 請求的資源（網頁等）不存在
500 - 內部服務器錯誤
HTTP狀態碼分類
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的做用。HTTP狀態碼共分爲5種類型：

分類 分類描述
1** 信息，服務器收到請求，須要請求者繼續執行操做
2** 成功，操做被成功接收並處理
3** 重定向，須要進一步的操做以完成請求
4** 客戶端錯誤，請求包含語法錯誤或沒法完成請求
5** 服務器錯誤，服務器在處理請求的過程當中發生了錯誤
HTTP狀態碼列表:

狀態碼 狀態碼英文名稱 中文描述
100 Continue 繼續。客戶端應繼續其請求
101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200 OK 請求成功。通常用於GET與POST請求
201 Created 已建立。成功請求並建立了新的資源
202 Accepted 已接受。已經接受請求，但未處理完成
203 Non-Authoritative Information 非受權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本
204 No Content 無內容。服務器成功處理，但未返回內容。在未更新網頁的狀況下，可確保瀏覽器繼續顯示當前文檔
205 Reset Content 重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可經過此返回碼清除瀏覽器的表單域
206 Partial Content 部份內容。服務器成功處理了部分GET請求
300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特徵與地址的列表用於用戶終端（例如：瀏覽器）選擇
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替
302 Found 臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI
303 See Other 查看其它地址。與301相似。使用GET和POST請求查看
304 Not Modified 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源
305 Use Proxy 使用代理。所請求的資源必須經過代理訪問
306 Unused 已經被廢棄的HTTP狀態碼
307 Temporary Redirect 臨時重定向。與302相似。使用GET請求重定向
400 Bad Request 客戶端請求的語法錯誤，服務器沒法理解
401 Unauthorized 請求要求用戶的身份認證
402 Payment Required 保留，未來使用
403 Forbidden 服務器理解請求客戶端的請求，可是拒絕執行此請求
404 Not Found 服務器沒法根據客戶端的請求找到資源（網頁）。經過此代碼，網站設計人員可設置」您所請求的資源沒法找到」的個性頁面
405 Method Not Allowed 客戶端請求中的方法被禁止
406 Not Acceptable 服務器沒法根據客戶端請求的內容特性完成請求
407 Proxy Authentication Required 請求要求代理的身份認證，與401相似，但請求者應當使用代理進行受權
408 Request Time-out 服務器等待客戶端發送的請求時間過長，超時
409 Conflict 服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了衝突
410 Gone 客戶端請求的資源已經不存在。410不一樣於404，若是資源之前有如今被永久刪除了可以使用410代碼，網站設計人員可經過301代碼指定資源的新位置
411 Length Required 服務器沒法處理客戶端發送的不帶Content-Length的請求信息
412 Precondition Failed 客戶端請求信息的先決條件錯誤
413 Request Entity Too Large 因爲請求的實體過大，服務器沒法處理，所以拒絕請求。爲防止客戶端的連續請求，服務器可能會關閉鏈接。若是隻是服務器暫時沒法處理，則會包含一個Retry-After的響應信息
414 Request-URI Too Large 請求的URI過長（URI一般爲網址），服務器沒法處理
415 Unsupported Media Type 服務器沒法處理請求附帶的媒體格式
416 Requested range not satisfiable 客戶端請求的範圍無效
417 Expectation Failed 服務器沒法知足Expect的請求頭信息
500 Internal Server Error 服務器內部錯誤，沒法完成請求
501 Not Implemented 服務器不支持請求的功能，沒法完成請求
502 Bad Gateway 充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求
503 Service Unavailable 因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504 Gateway Time-out 充當網關或代理的服務器，未及時從遠端服務器獲取請求
505 HTTP Version not supported 服務器不支持請求的HTTP協議的版本，沒法完成處理
HTTP請求格式
客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的通常格式。

img

常見請求頭 描述 （紅色掌握，其餘瞭解）
Referer 瀏覽器通知服務器，當前請求來自何處。若是是直接訪問，則不會有這個頭。經常使用於：防盜鏈
If-Modified-Since 瀏覽器通知服務器，本地緩存的最後變動時間。與另外一個響應頭組合控制瀏覽器頁面的緩存。
Cookie 與會話有關技術，用於存放瀏覽器緩存的cookie信息。
User-Agent 瀏覽器通知服務器，客戶端瀏覽器與操做系統相關信息
Connection 保持鏈接狀態。Keep-Alive 鏈接中，close 已關閉
Host 請求的服務器主機名
Content-Length 請求體的長度
Content-Type 若是是POST請求，會有這個頭，默認值爲application/x-www-form-urlencoded，表示請求體內容使用url編碼
Accept： 瀏覽器可支持的MIME類型。文件類型的一種描述方式。MIME格式：大類型/小類型[;參數]例如： text/html ，html文件 text/css，css文件 text/javascript，js文件 image/*，全部圖片文件
Accept-Encoding 瀏覽器通知服務器，瀏覽器支持的數據壓縮格式。如：GZIP壓縮
Accept-Language 瀏覽器通知服務器，瀏覽器支持的語言。各國語言（國際化i18n）
HTTP請求頭
請求頭中主要包含本次請求的附加消息，其中長用的字段有：

Accept：指定客戶端可以接收的內容類型

Accept-Encoding:指定瀏覽器能夠支持的web服務器返回內容壓縮編碼類型

Accept-Language:瀏覽器可接受的語言

Content-Length:請求的內容長度

Content-Type:請求的與實體對應的MIME信息

Date：請求發送的日期和時間

詳細的請求頭的全部完整內容請瀏覽：

http://tools.jb51.net/table/http_header

響應報文
響應行：包涵HTTP的版本和本次請求的狀態，就是響應碼。
響應頭：用於描述服務器的基本信息和數據。
Allow 服務器支持哪些請求方法（如GET、POST等）
Content-Encoding 文檔的編碼（Encode）方法。
Content-Length 表示內容長度。
Content-Type 表示後面的文檔屬於什麼MIME類型。
響應實體：包涵的就是客戶端從服務器中獲取的數據了，數據的格式和長度都會在響應體頭中描述。
詳細的請求頭的全部完整內容請瀏覽：http://tools.jb51.net/table/http_header

對比幾種python框架
Django，發佈於2003年，最初被用來製做在線新聞的Web站點。Django的各模塊之間結合的比較緊密，多一在功能強大的同時又是一個相對封閉的系統。

Thrnado：一個強大的、支持協程、高效併發且可擴展的Web服務器，發佈於2009年，它的強項在於能夠利用異步協程機制實現高併發的服務。

Flask：Python Web家族裏面比較年輕的一個，發佈於2010年，它吸取了其餘框架的優勢而且把本身的主要領域定義在微小的項目上，以短小精煉，簡潔明瞭著稱。

Twisted：一個有着10多年曆史的開源事件驅動框架，它不像前面的三種着眼於Web應用開發，而是適用從傳輸層到自定義應用協議的全部類型的網絡程序開發，並能在不一樣的操做系統上提供很高的運行效率，可是對python3的支持有限。

基於python的web開發技術棧

通常web框架的架構圖

django的特色
功能齊全，完善的文檔，強大的數據庫訪問組件（model的ORM組件），靈活的URL映射，豐富的template模板語言（相似jinja2模板語言），自帶免費的後臺管理系統，完整的錯誤信息提示。

MVC和MTV開發模式
MVC（model-view-contoller）：也被稱做軟件架構（flask使用該模式）

M：數據存取部分，由django數據層處理

V：選擇顯示哪些數據要以及怎麼顯示，由視圖和模板處理(js/html/css)

C：根據用戶輸入委派視圖的部分，由django框架經過URLconf設置，對給定URL調用合適的python函數來處理進行(至關於mtv的view)

MTV開發模式（model-template-view）：Django使用該模式

M 表明模型（Model），即數據存取層。該層處理與數據相關的全部事務：如何存取、如何確認有效性、包含哪些行爲以及數據之間的關係等。

T 表明模板(Template)，即表現層。該層處理與表現相關的決定：如何在頁面或其餘類型文檔中進行顯示。

V 表明視圖（View），即業務邏輯層。該層包含存取模型及調取恰當模板的相關邏輯。你能夠把它看做模型與模板之間的橋樑。

Django的MTV模型組織

經常使用的命令
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
鍵入：python manage.py
django-admin startproject projectname 建立django程序
startapp appname 建立app
runserver 啓動django服務
runserver 8001 當提示端口被佔用時，咱們能夠啓用其餘的端口
runserver 0.0.0.0:8000 監聽機器的全部ip

（下面兩個是配套使用的命令 ，先執行前面一個再執行後面一個） makemigrations #檢測model.py下的類是否有改動
migrate #將model.py下的代碼翻譯成sql語句

flush 清空數據庫
createsuperuser 建立超級管理員（用戶名和密碼必填）
changepassword username 修改用戶密碼
shell 啓動項目環境終端（就是ipython或者bpython）
dbshell 自動進入settings配置的數據庫，在這個終端能夠執行數據庫的sql語句

在終端輸入python manage.py 能夠查看更多的命令
Django處理請求的本質
簡單一點就是寫視圖函數views並用URLconfs把他們和URLs連接起來。詳細：當server收到一個Http請求之後，server特定的handler會建立HTTPRequest並傳遞給下一個組件並處理。這個handler而後會調用全部可用的Request或者View中間件。只要中間件返回一個HTTPRequest，系統就跳過對視圖的處理。若是視圖函數拋出異常，控制器就會傳遞給異常處理中間件處理，若是這個中間件沒有返回HTTPRequest，那麼就不能處理這個異常，這個時候Django包含缺省的視圖生成友好的404和500的（request）.

Django功能文件解析
Manage.py:一種命令執行工具，可以使咱們以多種方式與Django項目進行交互

Settings.py:django項目的設置和配置，數據庫配置，app配置，靜態文件配置等等都在這裏面完成

urls.py:django項目的URL的聲明，也就是django所支撐站點的內容列表，就是網站的入口。

Templates：存放網頁模板html、css和js等

init.py：啓動應用所需的處理都在這裏，好比應用的入口，model的導入，數據庫鏈接的初始化，設置文件的讀取等，此外，文件的調用必須在package裏面有這個文件。

wsgi.py:一個基於WSGI的web服務器進入點，提供底層的網絡通訊功能一般不用關心，由於人家已經幫咱們作好了

URL 配置和鬆耦合
鬆耦合就是兩段代碼是這種關係，當咱們改變其中一個代碼的時候，不會影響另外的一段代碼，或者只是少量的影響。在Django中視圖函數和URL就是這種關係。其餘的使用緊耦合的對後期的維護與改動很是的不利。其實在這個架構中使用這種耦合的方式不少地方都有體現。

Django的模板系統
Python代碼編寫和HTML設計是兩項不一樣的工做。這樣講這兩項工做分離開進行就會是咱們的工做開展的更快。所以就須要咱們的系統模板：

基礎知識：概念：Django模板用於分割文檔的表示（presentation）和數據（data）的字符串文本。

模板包括：佔位符（placeholders）和各類定義文檔應該如何顯示的基本邏輯（即模板標籤，template tag）

在python代碼中使用系統模板，只須要遵循如下兩個步驟：

1，使用原始的模板代碼字符串建立一個Template對象；

2，調用Template對象的render（）方法並提供給他變量（i.e.,內容）。它將返回一個完整的模板字符串，包含了全部標籤塊和變量解析後的內容

自動化測試
爲何我會把自動化測試放在這裏，由於，咱們在這裏須要有一個概念：當咱們的一個項目搭建好了以後並不意味着任務的完結，反而須要各類方法去檢測咱們的代碼和邏輯。

測試是一種例行的、不可缺失的工做，用於檢查你的程序是否符合預期。

測試能夠分爲手動測試和自動測試。手動測試很常見，有時候print一個變量內容，均可以看作是測試的一部分。手動測試每每很零碎、不成體系、不夠完整、耗時費力、效率低下，測試結果也不必定準確。

自動化測試則是系統地較爲完整地對程序進行測試，效率高，準確性高，而且大部分共同的測試工做會由系統來幫你完成。一旦你建立了一組自動化測試程序，當你修改了你的應用，你就能夠用這組測試程序來檢查你的代碼是否仍然同預期的那樣運行，而無需執行耗時的手動測試。

建立一個測試實例：

1
2
3
4
5
6
7
8
9
10
11
12
13
import datetime
from django.utils import timezone
from django.test import TestCase
from .models import Question

class QuestionMethodTests(TestCase):
def test_was_published_recently_with_future_question(self):
"""
在未來發布的問卷應該返回False
"""
time = timezone.now() + datetime.timedelta(days=30)
future_question = Question(pub_date=time)
self.assertIs(future_question.was_published_recently(), False)
運行測試程序：

在終端運行：

1
python manage.py test app01
運行這行代碼都發生了什麼？

首先執行該命令以後，回去查找app01應用中全部的測試程序
發現一個django.test.TestCase的子類
爲測試建立一個專用的數據庫
查找test開頭的測試方法
在test_was_published_recently_with_future_question方法中，建立一個Question實例，該實例的pub_data字段的值是30天后的將來日期。
而後利用assertIs()方法，它發現was_published_recently()返回了True，而不是咱們但願的False。
最後，測試程序會通知咱們哪一個測試失敗了，錯誤出如今哪一行
自定義Admin後臺管理站點
jango的admin站點是自動生成的、高度可定製的，它是Django相較其它Web框架獨有的內容，廣受歡迎。若是你以爲它不夠美觀，還有第三方美化版xadmin。請必定不要忽略它，相信我，它值得擁有！

簡單的配置：http://www.liujiangblog.com/course/django/93