理解Restful 架構

時間 2019-11-12

標籤理解 restful 架構欄目系統架構简体版

原文原文鏈接

理解Restful 架構

新型的軟件 —— 網站即軟件

互聯網軟件採用客戶端/ 服務器模式，創建在分佈式體系上，經過互聯網通訊，有高延時，高併發特色。

軟件開發主要針對單機環境，網路則主要是研究系統之間的通訊。如今咱們必須考慮，如何開發在互聯網環境中使用的軟件。

Restful 架構，是目前最流行的一種互聯網軟件架構。結構清晰，符合表中，易於理解，擴展方便。

一、起源：

REST 被誰提出的，Roy Thomas Fielding 寫的一篇論文提到這種概念。

下面是Fielding 論文的大體目的：

軟件 和 網路     計算機領域兩大前沿
 
軟件 更多人關注軟件的設計。 不多有人評估 設計選擇對系統行爲的影響
 
網絡 關注系統之間通訊行爲的細節、改進特定通訊機制的表現，———— 忽略一個事實： 改變應用程序的互動風格 比 改變互動協議，對總體表現有更大的影響。
 
Fielding 寫這篇論文的目的就是： 在符合架構原理的前提下，理解和評估以網絡爲基礎的應用軟件的架構設計，獲得一個功能強、性能好、適宜通訊的架構。

二、名稱

Fielding 將他對互聯網軟件的架構原則，定義爲 REST ，即 Repressentational State Transfer 的縮寫。翻譯成中文是「表現層狀態轉化」。

若是一個架構符合REST 原則，就稱它爲RESTFUL 架構。

3、資源

REST 的名稱「表現層狀態轉化」中，省略了主語。「表現層」指的是「資源」的表現層。

」資源「是網絡上的一個實體，或者說是網絡上的一個具體信息。每種資源對應一個特定的URI（統一資源定位符），要獲取這個資源，訪問它的URI 就能夠。

所謂「上網」，就是與互聯網上一些列的「資源」互動，調用它的URI。

4、表現層（representation）

「資源」是一種信息實體，它能夠有多種外在表現形式。咱們把「資源」具體呈現出來的形式，叫作它的「表現層」。

URI 只表明資源的實體，不表明它的形式。

資源的具體表現形式，在 HTTP 請求頭信息中，用Accept 和 Content-type 字段指定。

5、狀態轉化（State Transfer）

訪問一個網站，就表明了客戶端和服務器的一個互動過程。在這個過程當中，勢必涉及到數據和狀態的變化。

互聯網通訊協議 HTTP協議，是一個無狀態協議。這意味着，全部的狀態都保存在服務器端。所以，客戶端想要操控服務器，必須經過某種手段，讓服務端發生「狀態轉化」，而這種轉化是創建在表現層之上的，因此就是「表現層狀態轉化」。

客戶端能用的手段就是HTTP協議，請求頭裏四個表示操做方式的動詞：

GET 、POST 、 PUT、DELETE。表明四種操做：GET 用來獲取資源，POST 用來新建資源（也能夠用於更新資源），PUT 用來更新資源，DELETE 用來刪除資源。

6、綜述

總結一下什麼是 RESTFUL 架構：

（1）每個URI 表明一種資源；

（2）客戶端和服務器之間，傳遞這種資源的某種表現層。

（3）客戶端經過四個HTTP 動詞，對服務端資源進行操做，實現「表現層狀態轉化」；

7、誤區

最多見的一種設計錯誤，就是URI 包含動詞。

由於"資源"表示一種實體，因此應該是名詞，URI不該該有動詞，動詞應該放在HTTP協議中。

另外一個設計誤區，就是在URI中加入版本號：

由於不一樣的版本，能夠理解成同一種資源的不一樣表現形式，因此應該採用同一個URI。

過濾信息

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

下面是一些常見的參數。

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