關于RESTful架構(gòu)的設計

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

關于RESTful架構(gòu)的設計

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

（廈門安勝網(wǎng)絡科技有限公司 福建 321008）

REST完整表示的意思是形態(tài)的轉(zhuǎn)移，在滿足形態(tài)架構(gòu)的基礎上，在以網(wǎng)絡為基礎的應用軟件設計的架構(gòu)上，得到一個功能完善、性能穩(wěn)定、適合于通信的結(jié)構(gòu)。如果一個平臺結(jié)構(gòu)符合REST的原則和約束規(guī)范，則說明這是RESTful架構(gòu)。

資源；URL；鏈接；版本號

0 前言

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

1 URI的表述

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

2 資源接口的統(tǒng)一

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

3 請求方法實踐

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

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

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

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

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

4 資源的描述

客戶端與服務端之間其實傳遞的只是一種資源的描述，而不是將資源進行傳遞。比如說，某些文本數(shù)據(jù)的傳遞，我們可以使用json,xml等格式進行傳遞，然后再將其中的描述在客戶端與服務端之間以數(shù)據(jù)流的形式進行傳輸，這樣不僅可以使得文本數(shù)據(jù)保持安全性。如果是某些圖片的數(shù)據(jù)，圖片資源是無法直接傳輸?shù)模枰獙⑵涿枋鰹榱鞯男问竭M行傳輸，當其傳輸?shù)椒掌髦螅龠M行解析為圖片。

5 理解鏈接

資源之間也是需要鏈接起來的，這樣不同資源之間可以相互關聯(lián)起來，而非獨立。因此在資源的描述中，需要加入鏈接來引導我們的客戶端。往往資源之間需要相互跳轉(zhuǎn)，相互協(xié)調(diào)的。因此在數(shù)據(jù)傳輸?shù)母袷街校枰尤腈溄訉傩裕虼丝蛻舳瞬艜鶕?jù)鏈接來進行引導[4]。

6 狀態(tài)的理解

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

7 總結(jié)

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

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

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

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

[4]于麗.基于UML的面向?qū)ο蠼＜夹g研究與應用[J].信息與電腦(理論版),2015.