Web應(yīng)用模式

在開發(fā)Web應(yīng)用中，有兩種應(yīng)用模式：

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

1 前后端不分離

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

這種應(yīng)用模式比較適合純網(wǎng)頁應(yīng)用，但是當(dāng)后端對接App時(shí)，App可能并不需要后端返回一個(gè)HTML網(wǎng)頁，而僅僅是數(shù)據(jù)本身，所以后端原本返回網(wǎng)頁的接口不再適用于前端App應(yīng)用，為了對接App后端還需再開發(fā)一套接口。

2 前后端分離

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

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

在前后端分離的應(yīng)用模式中，我們通常將后端開發(fā)的每個(gè)視圖都稱為一個(gè)接口，或者API，前端通過訪問接口來對數(shù)據(jù)進(jìn)行增刪改查。

認(rèn)識RESTful

即Representational State Transfer的縮寫。維基百科稱其為“具象狀態(tài)傳輸”，國內(nèi)大部分人理解為“表現(xiàn)層狀態(tài)轉(zhuǎn)化”。

RESTful是一種開發(fā)理念。維基百科說：REST是設(shè)計(jì)風(fēng)格而不是標(biāo)準(zhǔn)。 REST描述的是在網(wǎng)絡(luò)中client和server的一種交互形式；REST本身不實(shí)用，實(shí)用的是如何設(shè)計(jì) RESTful API（REST風(fēng)格的網(wǎng)絡(luò)接口）,一種萬維網(wǎng)軟件架構(gòu)風(fēng)格。

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

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

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

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

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

要理解RESTful架構(gòu)，理解Representational State Transfer這三個(gè)單詞的意思。

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

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

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

• 狀態(tài)轉(zhuǎn)換，?就是客戶端和服務(wù)器互動的一個(gè)過程，在這個(gè)過程中, 勢必涉及到數(shù)據(jù)和狀態(tài)的變化, 這種變化叫做狀態(tài)轉(zhuǎn)換。

  互聯(lián)網(wǎng)通信協(xié)議HTTP協(xié)議，客戶端訪問必然使用HTTP協(xié)議，如果客戶端想要操作服務(wù)器，必須通過某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）。

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

  而且HTTP協(xié)議是一種無狀態(tài)協(xié)議，這樣就必須把所有的狀態(tài)都保存在服務(wù)器端。因此，如果客戶端想要操作服務(wù)器，必須通過某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）

總結(jié)

綜合上面的解釋，RESTful架構(gòu)就是：

• 每一個(gè)URL代表一種資源；
• 客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；
• 客戶端通過四個(gè)HTTP動詞，對服務(wù)器端資源進(jìn)行操作，實(shí)現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。

RESTful設(shè)計(jì)方法

1. 域名

應(yīng)該盡量將API部署在專用域名之下。

https://api.example.com

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

https://example.org/api/

2. 版本（Versioning）

應(yīng)該將API的版本號放入U(xiǎn)RL。

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

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

因?yàn)椴煌陌姹?#xff0c;可以理解成同一種資源的不同表現(xiàn)形式，所以應(yīng)該采用同一個(gè)URL。版本號可以在HTTP請求頭信息的Accept字段中進(jìn)行區(qū)分（參見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）

路徑又稱"終點(diǎn)"（endpoint），表示API的具體網(wǎng)址，每個(gè)網(wǎng)址代表一種資源（resource）

(1) 資源作為網(wǎng)址，只能有名詞，不能有動詞，而且所用的名詞往往與數(shù)據(jù)庫的表名對應(yīng)。

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

/getProducts /listOrders /retreiveClientByOrder?orderId=1

對于一個(gè)簡潔結(jié)構(gòu)，你應(yīng)該始終用名詞。 此外，利用的HTTP方法可以分離網(wǎng)址中的資源名稱的操作。

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

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

舉例來說，獲取產(chǎn)品的API可以這樣定義

獲取單個(gè)產(chǎn)品：http://127.0.0.1:8080/AppName/rest/products/1 獲取所有產(chǎn)品: http://127.0.0.1:8080/AppName/rest/products

3. HTTP動詞

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

常用的HTTP動詞有下面四個(gè)（括號里是對應(yīng)的SQL命令）。

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

還有三個(gè)不常用的HTTP動詞。

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

下面是一些例子。

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

4. 過濾信息（Filtering）

如果記錄數(shù)量很多，服務(wù)器不可能都將它們返回給用戶。API應(yīng)該提供參數(shù)，過濾返回結(jié)果。

下面是一些常見的參數(shù)。

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

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

6. 狀態(tài)碼（Status Codes）

服務(wù)器向用戶返回的狀態(tài)碼和提示信息，常見的有以下一些（方括號中是該狀態(tài)碼對應(yīng)的HTTP動詞）。

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

7. 錯(cuò)誤處理（Error handling）

如果狀態(tài)碼是4xx，服務(wù)器就應(yīng)該向用戶返回出錯(cuò)信息。一般來說，返回的信息中將error作為鍵名，出錯(cuò)信息作為鍵值即可。

{error: "Invalid API key" }

8. 返回結(jié)果

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

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

9. 超媒體（Hypermedia API）

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

比如，Github的API就是這種設(shè)計(jì)，訪問api.github.com會得到一個(gè)所有可用API的網(wǎng)址列表。

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

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

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

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

10. 其他

服務(wù)器返回的數(shù)據(jù)格式，應(yīng)該盡量使用JSON，避免使用XML。

+ View Code

明確REST接口開發(fā)的核心任務(wù)

分析一下上節(jié)的案例，可以發(fā)現(xiàn)，在開發(fā)REST API接口時(shí)，視圖中做的最主要有三件事：

• 將請求的數(shù)據(jù)（如JSON格式）轉(zhuǎn)換為模型類對象
• 操作數(shù)據(jù)庫
• 將模型類對象轉(zhuǎn)換為響應(yīng)的數(shù)據(jù)（如JSON格式）

序列化Serialization

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

序列化（serialization）在計(jì)算機(jī)科學(xué)的資料處理中，是指將數(shù)據(jù)結(jié)構(gòu)或物件狀態(tài)轉(zhuǎn)換成可取用格式（例如存成檔案，存于緩沖，或經(jīng)由網(wǎng)絡(luò)中傳送），以留待后續(xù)在相同或另一臺計(jì)算機(jī)環(huán)境中，能恢復(fù)原先狀態(tài)的過程。依照序列化格式重新獲取字節(jié)的結(jié)果時(shí)，可以利用它來產(chǎn)生與原始物件相同語義的副本。對于許多物件，像是使用大量參照的復(fù)雜物件，這種序列化重建的過程并不容易。面向?qū)ο笾械奈锛蛄谢?#xff0c;并不概括之前原始物件所關(guān)聯(lián)的函式。這種過程也稱為物件編組（marshalling）。從一系列字節(jié)提取數(shù)據(jù)結(jié)構(gòu)的反向操作，是反序列化（也稱為解編組, deserialization, unmarshalling）。

序列化在計(jì)算機(jī)科學(xué)中通常有以下定義:

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

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

將程序中的一個(gè)數(shù)據(jù)結(jié)構(gòu)類型轉(zhuǎn)換為其他格式（字典、JSON、XML等），例如將Django中的模型類對象裝換為JSON字符串，這個(gè)轉(zhuǎn)換過程我們稱為序列化。

如：

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等）轉(zhuǎn)換為程序中的數(shù)據(jù)，例如將JSON字符串轉(zhuǎn)換為Django中的模型類對象，這個(gè)過程我們稱為反序列化。

如：

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() )

我們可以看到，在開發(fā)REST API時(shí)，視圖中要頻繁的進(jìn)行序列化與反序列化的編寫。

總結(jié)

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

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

• 將前端發(fā)送的數(shù)據(jù)反序列化為模型類對象，并保存到數(shù)據(jù)庫中。

Django REST framework 簡介

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

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

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

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

認(rèn)識Django REST framewor

Django REST framework 框架是一個(gè)用于構(gòu)建Web API 的強(qiáng)大而又靈活的工具。

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

DRF框架是建立在Django框架基礎(chǔ)之上，由Tom Christie大牛二次開發(fā)的開源項(xiàng)目。

特點(diǎn)

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/renshida/p/10323425.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。