Web應用模式

在開發Web應用中，有兩種應用模式：

• 前后端不分離
• 前后端分離

1 前后端不分離

在前后端不分離的應用模式中，前端頁面看到的效果都是由后端控制，由后端渲染頁面或重定向，也就是后端需要控制前端的展示，前端與后端的耦合度很高。

這種應用模式比較適合純網頁應用，但是當后端對接App時，App可能并不需要后端返回一個HTML網頁，而僅僅是數據本身，所以后端原本返回網頁的接口不再適用于前端App應用，為了對接App后端還需再開發一套接口。

2 前后端分離

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

在前后端分離的應用模式中 ，前端與后端的耦合度相對較低。

在前后端分離的應用模式中，我們通常將后端開發的每個視圖都稱為一個接口，或者API，前端通過訪問接口來對數據進行增刪改查。

認識RESTful

即Representational State Transfer的縮寫。維基百科稱其為“具象狀態傳輸”，國內大部分人理解為“表現層狀態轉化”。

RESTful是一種開發理念。維基百科說：REST是設計風格而不是標準。 REST描述的是在網絡中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網絡接口）,一種萬維網軟件架構風格。

我們先來具體看下RESTful風格的url,比如我要查詢商品信息，那么

非REST的url：http://.../queryGoods?id=1001&type=t01

REST的url:?http://.../t01/goods/1001

可以看出REST特點：url簡潔，將參數通過url傳到服務器，而傳統的url比較啰嗦，而且現實中瀏覽器地址欄會拼接一大串字符，想必你們都見過吧。但是采用REST的風格就會好很多，現在很多的網站已經采用這種風格了，這也是潮流方向，典型的就是url的短化轉換。

那么，到底什么是RESTFul架構： 如果一個架構符合REST原則，就稱它為RESTful架構。

要理解RESTful架構，理解Representational State Transfer這三個單詞的意思。

• 具象的，就是指表現層，要表現的對象也就是“資源”，什么是資源呢？網站就是資源共享的東西，客戶端（瀏覽器）訪問web服務器，所獲取的就叫資源。比如html，txt，json，圖片，視頻等等。

• 表現，比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以采用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。

  瀏覽器通過URL確定一個資源，但是如何確定它的具體表現形式呢？應該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段才是對"表現層"的描述。

• 狀態轉換，?就是客戶端和服務器互動的一個過程，在這個過程中, 勢必涉及到數據和狀態的變化, 這種變化叫做狀態轉換。

  互聯網通信協議HTTP協議，客戶端訪問必然使用HTTP協議，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。

  HTTP協議實際上含有4個表示操作方式的動詞，分別是 GET,POST,PUT,DELETE,他們分別對應四種操作。GET用于獲取資源，POST用于新建資源，PUT用于更新資源，DElETE用于刪除資源。GET和POST是表單提交的兩種基本方式，比較常見，而PUT和DElETE不太常用。

  而且HTTP協議是一種無狀態協議，這樣就必須把所有的狀態都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）

總結

綜合上面的解釋，RESTful架構就是：

• 每一個URL代表一種資源；
• 客戶端和服務器之間，傳遞這種資源的某種表現層；
• 客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現"表現層狀態轉化"。

RESTful設計方法

1. 域名

應該盡量將API部署在專用域名之下。

https://api.example.com

如果確定API很簡單，不會有進一步擴展，可以考慮放在主域名下。

https://example.org/api/

2. 版本（Versioning）

應該將API的版本號放入URL。

http://www.example.com/app/1.0/foohttp://www.example.com/app/1.1/foohttp://www.example.com/app/2.0/foo

另一種做法是，將版本號放在HTTP頭信息中，但不如放入URL方便和直觀。Github采用這種做法。

因為不同的版本，可以理解成同一種資源的不同表現形式，所以應該采用同一個URL。版本號可以在HTTP請求頭信息的Accept字段中進行區分（參見Versioning REST Services）：

Accept: vnd.example-com.foo+json; version=1.0Accept: vnd.example-com.foo+json; version=1.1 Accept: vnd.example-com.foo+json; version=2.0

3. 路徑（Endpoint）

路徑又稱"終點"（endpoint），表示API的具體網址，每個網址代表一種資源（resource）

(1) 資源作為網址，只能有名詞，不能有動詞，而且所用的名詞往往與數據庫的表名對應。

舉例來說，以下是不好的例子:

/getProducts /listOrders /retreiveClientByOrder?orderId=1

對于一個簡潔結構，你應該始終用名詞。 此外，利用的HTTP方法可以分離網址中的資源名稱的操作。

GET /products ：將返回所有產品清單 POST /products ：將產品新建到集合 GET /products/4 ：將獲取產品 4 PATCH（或）PUT /products/4 ：將更新產品 4

(2) API中的名詞應該使用復數。無論子資源或者所有資源。

舉例來說，獲取產品的API可以這樣定義

獲取單個產品：http://127.0.0.1:8080/AppName/rest/products/1 獲取所有產品: http://127.0.0.1:8080/AppName/rest/products

3. HTTP動詞

對于資源的具體操作類型，由HTTP動詞表示。

常用的HTTP動詞有下面四個（括號里是對應的SQL命令）。

• GET（SELECT）：從服務器取出資源（一項或多項）。
• POST（CREATE）：在服務器新建一個資源。
• PUT（UPDATE）：在服務器更新資源（客戶端提供改變后的完整資源）。
• DELETE（DELETE）：從服務器刪除資源。

還有三個不常用的HTTP動詞。

• PATCH（UPDATE）：在服務器更新(更新)資源（客戶端提供改變的屬性）。
• HEAD：獲取資源的元數據。
• OPTIONS：獲取信息，關于資源的哪些屬性是客戶端可以改變的。

下面是一些例子。

GET /zoos：列出所有動物園 POST /zoos：新建一個動物園（上傳文件） GET /zoos/ID：獲取某個指定動物園的信息 PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息） PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息） DELETE /zoos/ID：刪除某個動物園 GET /zoos/ID/animals：列出某個指定動物園的所有動物 DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物

4. 過濾信息（Filtering）

如果記錄數量很多，服務器不可能都將它們返回給用戶。API應該提供參數，過濾返回結果。

下面是一些常見的參數。

?limit=10：指定返回記錄的數量 ?offset=10：指定返回記錄的開始位置。 ?page=2&per_page=100：指定第幾頁，以及每頁的記錄數。 ?sortby=name&order=asc：指定返回結果按照哪個屬性排序，以及排序順序。 ?animal_type_id=1：指定篩選條件

參數的設計允許存在冗余，即允許API路徑和URL參數偶爾有重復。比如，GET /zoos/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的。

6. 狀態碼（Status Codes）

服務器向用戶返回的狀態碼和提示信息，常見的有以下一些（方括號中是該狀態碼對應的HTTP動詞）。

• 200 OK - [GET]：服務器成功返回用戶請求的數據
• 201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數據成功。
• 202 Accepted - [*]：表示一個請求已經進入后臺排隊（異步任務）
• 204 NO CONTENT - [DELETE]：用戶刪除數據成功。
• 400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發出的請求有錯誤，服務器沒有進行新建或修改數據的操作
• 401 Unauthorized - [*]：表示用戶沒有權限（令牌、用戶名、密碼錯誤）。
• 403 Forbidden - [*] 表示用戶得到授權（與401錯誤相對），但是訪問是被禁止的。
• 404 NOT FOUND - [*]：用戶發出的請求針對的是不存在的記錄，服務器沒有進行操作，該操作是冪等的。
• 406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求JSON格式，但是只有XML格式）。
• 410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
• 422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時，發生一個驗證錯誤。
• 500 INTERNAL SERVER ERROR - [*]：服務器發生錯誤，用戶將無法判斷發出的請求是否成功。

7. 錯誤處理（Error handling）

如果狀態碼是4xx，服務器就應該向用戶返回出錯信息。一般來說，返回的信息中將error作為鍵名，出錯信息作為鍵值即可。

{error: "Invalid API key" }

8. 返回結果

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

• GET /collection：返回資源對象的列表（數組）
• GET /collection/resource：返回單個資源對象
• POST /collection：返回新生成的資源對象
• PUT /collection/resource：返回完整的資源對象
• PATCH /collection/resource：返回完整的資源對象
• DELETE /collection/resource：返回一個空文檔

9. 超媒體（Hypermedia API）

RESTful API最好做到Hypermedia（即返回結果中提供鏈接，連向其他API方法），使得用戶不查文檔，也知道下一步應該做什么。

比如，Github的API就是這種設計，訪問api.github.com會得到一個所有可用API的網址列表。

{ "current_user_url": "https://api.github.com/user", "authorizations_url": "https://api.github.com/authorizations", // ... }

從上面可以看到，如果想獲取當前用戶的信息，應該去訪問api.github.com/user，然后就得到了下面結果。

{"message": "Requires authentication","documentation_url": "https://developer.github.com/v3" }

上面代碼表示，服務器給出了提示信息，以及文檔的網址。

10. 其他

服務器返回的數據格式，應該盡量使用JSON，避免使用XML。

+ View Code

明確REST接口開發的核心任務

分析一下上節的案例，可以發現，在開發REST API接口時，視圖中做的最主要有三件事：

• 將請求的數據（如JSON格式）轉換為模型類對象
• 操作數據庫
• 將模型類對象轉換為響應的數據（如JSON格式）

序列化Serialization

維基百科中對于序列化的定義：

序列化（serialization）在計算機科學的資料處理中，是指將數據結構或物件狀態轉換成可取用格式（例如存成檔案，存于緩沖，或經由網絡中傳送），以留待后續在相同或另一臺計算機環境中，能恢復原先狀態的過程。依照序列化格式重新獲取字節的結果時，可以利用它來產生與原始物件相同語義的副本。對于許多物件，像是使用大量參照的復雜物件，這種序列化重建的過程并不容易。面向對象中的物件序列化，并不概括之前原始物件所關聯的函式。這種過程也稱為物件編組（marshalling）。從一系列字節提取數據結構的反向操作，是反序列化（也稱為解編組, deserialization, unmarshalling）。

序列化在計算機科學中通常有以下定義:

? 在數據儲存與傳送的部分是指將一個對象)存儲至一個儲存媒介，例如檔案或是記億體緩沖等，或者透過網絡傳送資料時進行編碼的過程，可以是字節或是XML等格式。而字節的或XML編碼格式可以還原完全相等的對象)。這程序被應用在不同應用程序之間傳送對象)，以及服務器將對象)儲存到檔案或數據庫。相反的過程又稱為反序列化。

簡而言之，我們可以將序列化理解為：

將程序中的一個數據結構類型轉換為其他格式（字典、JSON、XML等），例如將Django中的模型類對象裝換為JSON字符串，這個轉換過程我們稱為序列化。

如：

queryset = BookInfo.objects.all() book_list = [] # 序列化 for book in queryset: book_list.append({ ‘id‘: book.id, ‘btitle‘: book.btitle, ‘bpub_date‘: book.bpub_date, ‘bread‘: book.bread, ‘bcomment‘: book.bcomment, ‘image‘: book.image.url if book.image else ‘‘ }) return JsonResponse(book_list, safe=False)

反之，將其他格式（字典、JSON、XML等）轉換為程序中的數據，例如將JSON字符串轉換為Django中的模型類對象，這個過程我們稱為反序列化。

如：

json_bytes = request.body json_str = json_bytes.decode()# 反序列化 book_dict = json.loads(json_str) book = BookInfo.objects.create(btitle=book_dict.get(‘btitle‘),bpub_date=datetime.strptime(book_dict.get(‘bpub_date‘), ‘%Y-%m-%d‘).date() )

我們可以看到，在開發REST API時，視圖中要頻繁的進行序列化與反序列化的編寫。

總結

在開發REST API接口時，我們在視圖中需要做的最核心的事是：

• 將數據庫數據序列化為前端所需要的格式，并返回；

• 將前端發送的數據反序列化為模型類對象，并保存到數據庫中。

Django REST framework 簡介

在序列化與反序列化時，雖然操作的數據不盡相同，但是執行的過程卻是相似的，也就是說這部分代碼是可以復用簡化編寫的。

在開發REST API的視圖中，雖然每個視圖具體操作的數據不同，但增、刪、改、查的實現流程基本套路化，所以這部分代碼也是可以復用簡化編寫的：

• 增：校驗請求數據 -> 執行反序列化過程 -> 保存數據庫 -> 將保存的對象序列化并返回
• 刪：判斷要刪除的數據是否存在 -> 執行數據庫刪除
• 改：判斷要修改的數據是否存在 -> 校驗請求的數據 -> 執行反序列化過程 -> 保存數據庫 -> 將保存的對象序列化并返回
• 查：查詢數據庫 -> 將數據序列化并返回

Django REST framework可以幫助我們簡化上述兩部分的代碼編寫，大大提高REST API的開發速度。

認識Django REST framewor

Django REST framework 框架是一個用于構建Web API 的強大而又靈活的工具。

通常簡稱為DRF框架 或 REST framework。

DRF框架是建立在Django框架基礎之上，由Tom Christie大牛二次開發的開源項目。

特點

• 提供了定義序列化器Serializer的方法，可以快速根據 Django ORM 或者其它庫自動序列化/反序列化；
• 提供了豐富的類視圖、Mixin擴展類，簡化視圖的編寫；
• 豐富的定制層級：函數視圖、類視圖、視圖集合到自動生成 API，滿足各種需要；
• 多種身份認證和權限認證方式的支持；
• 內置了限流系統；
• 直觀的 API web 界面；
• 可擴展性，插件豐富

?

轉載于:https://www.cnblogs.com/renshida/p/10323425.html

總結

以上是生活随笔為你收集整理的DRF (Django REST framework) 框架介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

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