前后端不分離

在前后端不分離的應用模式中，前端頁面看到的效果都是由后端控制，由后端渲染頁面或重定向，也就是后端需要控制前端的展示，前端與后端的耦合度很高。這種應用模式比較適合純網頁應用，但是當后端對接App時，App可能并不需要后端返回一個HTML網頁，而僅僅是數據本身，所以后端原本返回網頁的接口不適用于前端App應用，為了對接App后端還需再開發(fā)一套接口。

前后端分離

在前后端分離的應用模式中，后端僅返回前端所需的數據，不再渲染HTML頁面，不再控制前端的效果。至于前端用戶看到什么效果，從后端請求的數據如何加載到前端中，都由前端自己決定，網頁有網頁的處理方式，App有App的處理方式，但無論哪種前端，所需的數據基本相同，后端僅需開發(fā)一套邏輯對外提供數據即可。

在前后端分離的應用模式中,我們通常將后端開發(fā)的每一視圖都稱為一個接口，或者API，前端通過訪問接口來對數據進行增刪改查。API的風格有多種，但是現(xiàn)在比較主流且實用的就是本文要說的RESTful API。

RESTful

RESTful是一種軟件架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用于客戶端和服務器交互類的軟件。基于這個風格設計的軟件可以更簡潔，更有層次，更易于實現(xiàn)緩存等機制。

REST全稱是Representational State Transfer，中文意思是 表征狀態(tài)轉移 。 它首次出現(xiàn)在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規(guī)范的主要編寫者之一。 他在論文中提到："我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。REST指的是一組架構約束條件和原則。" 如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構。

REST本身并沒有創(chuàng)造新的技術、組件或服務，而隱藏在RESTful背后的理念就是使用Web的現(xiàn)有特征和能力， 更好地使用現(xiàn)有Web標準中的一些準則和約束。雖然REST本身受Web技術的影響很深， 但是理論上REST架構風格并不是綁定在HTTP上，只不過目前HTTP是唯一與REST相關的實例。

RESTful的核心操作：URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。

那這種風格的接口有什么好處呢？可以前后端分離。前端拿到數據只負責展示和渲染，不對數據做任何處理。后端處理數據并以JSON格式傳輸出去，定義這樣一套統(tǒng)一的接口，在web，ios，android三端都可以用相同的接口。

RESTful實踐

API與用戶的通信協(xié)議，盡量使用HTTPs協(xié)議。
域名

https://api.example.com 最好不要用這種（會存在跨域問題）
https://example.org/api/ API很簡單

版本

URL，如：https://api.example.com/v1/
包含在請求頭中

url，任何東西都是資源，均使用名詞表示（可復數）

https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees

method

GET ：從服務器取出資源（一項或多項）
POST ：在服務器新建一個資源
PUT ：在服務器更新資源（客戶端提供改變后的完整資源），完整更新
PATCH ：在服務器更新資源（客戶端提供改變的屬性），局部更新，可能不支持
DELETE ：從服務器刪除資源

過濾，通過在url上傳參的形式傳遞搜索條件

https://api.example.com/v1/zoos?limit=10：指定返回記錄的數量
https://api.example.com/v1/zoos?o?set=10：指定返回記錄的開始位置
https://api.example.com/v1/zoos?page=2&per_page=100：指定第幾頁，以及每頁的記錄數
https://api.example.com/v1/zoos?sortby=name&order=asc：指定返回結果按照哪個屬性排序，以及排序順序
https://api.example.com/v1/zoos?animal_type_id=1：指定篩選條件

狀態(tài)碼 + code信息

　

錯誤處理，狀態(tài)碼是4xx時，應返回錯誤信息。

　

返回結果，針對不同操作，服務器向用戶返回的結果應該符合以下規(guī)范

HTTP請求方法詳解

請求方法：指定了客戶端想對指定的資源/服務器作何種操作

根據HTTP標準，HTTP請求可以使用多種請求方法。

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

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

GET：獲取資源

GET方法用來請求已被URI識別的資源。指定的資源經服務器端解析后返回響應內容（也就是說，如果請求的資源是文本，那就保持原樣返回；如果是CGI[通用網關接口]那樣的程序，則返回經過執(zhí)行后的輸出結果）。 最常用于向服務器查詢某些信息。必要時，可以將查詢字符串參數追加到URL末尾，以便將信息發(fā)送給服務器。

POST：傳輸實體文本

POST方法用來傳輸實體的主體。 雖然用GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸，而是用POST方法；雖然GET方法和POST方法很相似，但是POST的主要目的并不是獲取響應的主體內容。 POST請求的主體可以包含非常多的數據，而且格式不限。

GET方法和POST方法本質上的區(qū)別：

1、GET方法用于信息獲取，它是安全的（安全：指非修改信息，如數據庫方面的信息），而POST方法是用于修改服務器上資源的請求；

2、GET請求的數據會附在URL之后，而POST方法提交的數據則放置在HTTP報文實體的主體里，所以POST方法的安全性比GET方法要高；

3、GET方法傳輸的數據量一般限制在2KB，其原因在于：GET是通過URL提交數據，而URL本身對于數據沒有限制，但是不同的瀏覽器對于URL是有限制的，比如IE瀏覽器對于URL的限制為2KB，而Chrome，F(xiàn)ireFox瀏覽器理論上對于URL是沒有限制的，它真正的限制取決于操作系統(tǒng)本身；POST方法對于數據大小是無限制的，真正影響到數據大小的是服務器處理程序的能力。

HEAD：獲得報文首部

HEAD方法和GET方法一樣，只是不返回報文的主體部分，用于確認URI的有效性及資源更新的日期時間等。 具體來說：1、判斷類型； 2、查看響應中的狀態(tài)碼，看對象是否存在（響應：請求執(zhí)行成功了，但無數據返回）； 3、測試資源是否被修改過 HEAD方法和GET方法的區(qū)別：GET方法有實體，HEAD方法無實體。

PUT：傳輸文件

PUT方法用來傳輸文件，就像FTP協(xié)議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存在請求URI指定的位置。但是HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，存在安全問題，故一般不用。

POST和PUT的區(qū)別

POST 方法用來傳輸實體的主體，PUT方法用來傳輸文件，自身不帶驗證機制。這兩個方法看起來都是講一個資源附加到服務器端的請求，但其實是不一樣的。一些狹窄的意見認為，POST方法用來創(chuàng)建資源，而PUT方法則用來更新資源。這個說法本身沒有問題，但是并沒有從根本上解釋了二者的區(qū)別。事實上，它們最根本的區(qū)別就是：POST方法不是冪等的，而PUT方法則有冪等性。那這又衍生出一個問題，什么是冪等？

冪等（idempotent、idempotence）是一個抽象代數的概念。在計算機中，可以這么理解，一個冪等操作的特點就是其任意多次執(zhí)行所產生的影響均與依次一次執(zhí)行的影響相同。POST在請求的時候，服務器會每次都創(chuàng)建一個文件，但是在PUT方法的時候只是簡單地更新，而不是去重新創(chuàng)建。因此PUT是冪等的。

DELETE：刪除資源

指明客戶端想讓服務器刪除某個資源，與PUT方法相反，按URI刪除指定資源OPTIONS：詢問支持的方法OPTIONS方法用來查詢針對請求URI指定資源支持的方法（客戶端詢問服務器可以提交哪些請求方法）

TRACE：追蹤路徑

客戶端可以對請求消息的傳輸路徑進行追蹤，TRACE方法是讓Web服務器端將之前的請求通信還給客戶端的方法

CONNECT：要求用隧道協(xié)議連接代理

CONNECT方法要求在與代理服務器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL（安全套接層）和TLS（傳輸層安全）協(xié)議把通信內容加密后經網絡隧道傳輸。

DRF

官網地址：https://www.django-rest-framework.org/

Django Rest Framework是一個強大且靈活的工具包，主要用以構建RESTful風格的Web API。Django REST Framework（以后簡稱DRF）可以在Django的基礎上迅速實現(xiàn)API，并且自身還帶有基于WEB的測試和瀏覽頁面，可以方便的測試自己的API。DRF幾乎是Django生態(tài)中進行前后端分離開發(fā)的默認庫。

Django REST Framework具有以下功能和特性：

自帶基于Web的可瀏覽的API，對于開發(fā)者非常有幫助
支持OAuth1a和OAuth2認證策略
支持ORM或非ORM數據源的序列化
高可自定制性，多種視圖類型可選
自動生成符合 RESTful 規(guī)范的 API
支持 OPTION、HEAD、POST、GET、PATCH、PUT、DELETE等HTTP方法
根據 Content-Type 來動態(tài)的返回數據類型（如HTML、json）
細粒度的權限管理（可到對象級別）
豐富的文檔和強大的社區(qū)支持
Mozilla、Red Hat、 Heroku和Eventbrite等知名公司正在使用

安裝：

pip install djangorestframework
pip install markdown # Markdown
pip install django-filter # 可選
pip install coreapi # 可選

coreapi（1.32.0+） - 支持模式生成和coreapi命令行工具。

Markdown（2.1.0+） - 可瀏覽API的Markdown支持。

django-filter（1.0.1+） - 過濾支持。

django-crispy-forms- 改進的HTML顯示過濾。

django-guardian（1.1.1+） - 對象級別的權限支持

安裝完畢，在項目配置文件中，注冊app：

INSTALLED_APPS = (
...
'rest_framework',
)

總結

以上是生活随笔為你收集整理的DRF--介绍和安装的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。