關于RESTful架構的設計

◆何 軍 陳貴民 黃惠海 鄭漢軍 陳思德

關于RESTful架構的設計

◆何 軍 陳貴民 黃惠海 鄭漢軍 陳思德

（廈門安勝網絡科技有限公司 福建 321008）

REST完整表示的意思是形態的轉移，在滿足形態架構的基礎上，在以網絡為基礎的應用軟件設計的架構上，得到一個功能完善、性能穩定、適合于通信的結構。如果一個平臺結構符合REST的原則和約束規范，則說明這是RESTful架構。

資源；URL；鏈接；版本號

0 前言

軟件的版本一般都是存在兼容性的，同時軟件也是不斷地維護和更新，所以軟件在后續的使用過程中，往往會存在多個版本，然而軟件的版本需要兼容性，這樣軟件在新的版本更新時，可以兼容舊的版本，而且對于使用者而言，對于舊功能的請求路徑，不會產生影響，對于新的功能請求地址，仍然可以訪問。這樣對于新舊功能，相互之間不會產生影響，這樣對于軟件系統的維護與使用，在兼容原有系統的功能的基礎，對軟件系統實現持續的新增和維護更新，帶來了很大的便利，同時也給我們的開發帶來了極大的優異[1]。

1 URI的表述

REST全稱是表述性狀態轉移，那表述是什么意思呢? 其實代表的就是資源。任何事物，只要有被引用到的價值，那就可以理解為一個資源。資源可以是實體(例如身份證號碼)，也可以是一個抽象概念(比如價值多少) 。URI既可以看成是資源的路徑，也可以看成是資源的全名。如果某些信息沒通過URI來表示，那它就不能算是一個資源， 只能算是資源中的某些信息而已。URI的設計應該遵循可尋址性原則，具有自描述性，需要在表現形式上給人以直觀上的關聯[2]。

2 資源接口的統一

RESTful結構必須遵從統一接口規則。接口規則需要程序編寫者遵循一定的接口規范，有著相應的約束語法規則，這樣的約束，既有利于接口資源的統一，同時對于編寫者和使用者而言，有規律可遵循。同時，對于資源來說，無論是什么樣的資源，都是使用相同的接口進行數據的查詢和資源的訪問。而且，對于所有的資源接口來說，都要符合HTTP的請求標準。不能逾越http網絡傳輸協議規范。而對于Http來說，它包含get,post，put等方法，例如get是安全且冪等性的，post是不安全和不冪等性的，之所以會產生這種情況，主要是從服務的狀態來評定的，倘若不發生改變，則是安全的。倘若發生影響，則是冪等性的。不同方法適用于不同的場景，需要我們在開發過程中根據具體需求做出相應的處理。

3 請求方法實踐

（1）HTTP有許多請求方法，put就是其中之一，當客戶需要提交數據到數據庫時，可以通過put請求方法，put方法在發生請求時，將會更新數據，同時也會將服務器的狀態進行相應的改變。因為，當我們在編寫更新或者提交數據的接口時，將會采用到put的請求方式。

（2）我們在開發RESTful接口的時候，往往可能存在一些頭部參數，或者設置一些透傳的屬性值，頭部參數可能隱含著真實的請求路徑或者請求方式，而透傳則是請求url時具體的請求參數體，可能是string的格式，也可能是json的格式，這個需要根據具體的業務需求進行確定。

（3）接口統一后仍然可以進行方法的擴展。但前提條件是拓展的方法必須要符合接口的規則和請求規范，不能脫離接口的統一性原則[3]。

（4）雖然我們在開發接口時，需要講究安全性原則。但是在實際的RESTful的開發過程中，或多或少的還是產生一些負面的作用。同時，服務器在產生源源不斷的請求時，這些負面的作用還是伴隨著產生，因為，開發人員在設計接口時，要盡可能的考慮到該url在請求時發生的服務器奔潰，空指針異常等負面的影響。

（5）對于接口的開發人員來說，需要制定一套統一的請求狀態碼，一方面來表示請求是否合法，另一方面也可表示該請求成功與否。而對于這套統一的狀態碼，需要開發人員與客戶相互協調溝通，以此來達到資源接口的統一性。同時，這些狀態碼要盡可能的詳細，通知也要附帶一定的指導意思，這樣既給后續維護人員帶來更新維護上的方面，業方面客戶進行理解使用。

4 資源的描述

客戶端與服務端之間其實傳遞的只是一種資源的描述，而不是將資源進行傳遞。比如說，某些文本數據的傳遞，我們可以使用json,xml等格式進行傳遞，然后再將其中的描述在客戶端與服務端之間以數據流的形式進行傳輸，這樣不僅可以使得文本數據保持安全性。如果是某些圖片的數據，圖片資源是無法直接傳輸的，需要將其描述為流的形式進行傳輸，當其傳輸到服務器之后，再進行解析為圖片。

5 理解鏈接

資源之間也是需要鏈接起來的，這樣不同資源之間可以相互關聯起來，而非獨立。因此在資源的描述中，需要加入鏈接來引導我們的客戶端。往往資源之間需要相互跳轉，相互協調的。因此在數據傳輸的格式中，需要加入鏈接屬性，因此客戶端才會根據鏈接來進行引導[4]。

6 狀態的理解

對于一個系統而言，它包含這兩種狀態，一種是應用的狀態，另一種是資源的狀態。應用的狀態指的是軟件系統的狀態，而資源的狀態指的是資源在請求的過程中，所擁有的狀態。因此，前者和客戶端有關，后者和服務器有關。而且，這二者之間的交互是無狀態的。并且在每次的請求當中，請求體將會包含我們所需的所有資源數據。同時，在實際的請求過程中，服務器才會使用到應用的狀態。這種通信原則有一個特點就是服務器和媒介之間可以獨立的解析資源請求和響應。當然了，實際的請求中也會有違反無狀態通信規則的情況，例如利用客戶端上的cookies來記錄某一個服務器的會話請求。

7 總結

本文從資源的定義、獲取、表述、關聯、狀態變遷等角度， 試圖快速理解RESTful架構背后的概念。RESTful架構與傳統的RPC、SOAP等方式在理念上有很大的不同，希望本文能對各位讀者理解REST有所幫助。

[1]陳冠元.軟件工程中的UML建模技術[J].電子技術與軟件工程,2018.

[2]劉傳會.基于UML2.0順序圖的高可信實時軟件建模技術研究[A].中國航空學會、中國航空研究院,2017.

[3]夏志龍.使用UML和Event-B構建基于云平臺的應用軟件模型[D].江蘇科技大學,2016.

[4]于麗.基于UML的面向對象建模技術研究與應用[J].信息與電腦(理論版),2015.