此文包含內(nèi)容

1）什么是RESTful
2）SOAP和REST的區(qū)別
3）如何設(shè)計RESTFul風(fēng)格API（動物園為例）
4）REST風(fēng)格的接口測試流程
5）如何編寫功能測試計劃
6）如何使用Postman驗證測試用例

1.什么是RESTful

RESTFUL是一種網(wǎng)絡(luò)應(yīng)用程序的設(shè)計風(fēng)格和開發(fā)方式，基于HTTP，可以使用XML格式定義或JSON格式定義。RESTFUL適用于移動互聯(lián)網(wǎng)廠商作為業(yè)務(wù)使能接口的場景，實現(xiàn)第三方OTT調(diào)用移動網(wǎng)絡(luò)資源的功能，動作類型為新增、變更、刪除所調(diào)用資源。（百度百科）

REST全稱是Representational State Transfer，中文意思是表述（編者注：通常譯為表征）性狀態(tài)轉(zhuǎn)移。它首次出現(xiàn)在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規(guī)范的主要編寫者之一。他在論文中提到："我這篇文章的寫作目的，就是想在符合架構(gòu)原理的前提下，理解和評估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計，得到一個功能強(qiáng)、性能好、適宜通信的架構(gòu)。REST指的是一組架構(gòu)約束條件和原則。" 如果一個架構(gòu)符合REST的約束條件和原則，我們就稱它為RESTful架構(gòu)。

REST本身并沒有創(chuàng)造新的技術(shù)、組件或服務(wù)，而隱藏在RESTful背后的理念就是使用Web的現(xiàn)有特征和能力，更好地使用現(xiàn)有Web標(biāo)準(zhǔn)中的一些準(zhǔn)則和約束。雖然REST本身受Web技術(shù)的影響很深，但是理論上REST架構(gòu)風(fēng)格并不是綁定在HTTP上，只不過目前HTTP是唯一與REST相關(guān)的實例。（菜鳥教程）

restful

REST架構(gòu)的主要原則
· 對網(wǎng)絡(luò)上所有的資源都有一個資源標(biāo)志符。
· 對資源的操作不會改變標(biāo)識符。
· 同一資源有多種表現(xiàn)形式（xml、json）
· 所有操作都是無狀態(tài)的（Stateless）:使得客戶端和服務(wù)器端不必保存對方的詳細(xì)信息，服務(wù)器只需要處理當(dāng)前的請求，不需了解請求的歷史。可以更容易的釋放資源，讓服務(wù)器利用Pool（連接池）技術(shù)來提高穩(wěn)定性和性能。

符合上述REST原則的架構(gòu)方式稱為RESTful
RESTful是一種常見的REST應(yīng)用，是遵循REST風(fēng)格的web服務(wù)，REST式的web服務(wù)是一種ROA（面向資源的架構(gòu)）。

RESTful資源操作

資源請求格式

2.SOAP和REST的區(qū)別

SOAP

簡單對象訪問協(xié)議是一種基于 XML 的協(xié)議，可以和現(xiàn)存的許多因特網(wǎng)協(xié)議和格式結(jié)合使用，包括超文本傳輸協(xié)議（HTTP），簡單郵件傳輸協(xié)議（SMTP），多用途網(wǎng)際郵件擴(kuò)充協(xié)議（MIME），基于“通用”傳輸協(xié)議是 SOAP的一個優(yōu)點。它還支持從消息系統(tǒng)到遠(yuǎn)程過程調(diào)用等大量的應(yīng)用程序。SOAP提供了一系列的標(biāo)準(zhǔn)，如WSRM（WS-Reliable Messaging）形式化契約確保可靠性與安全性，確保異步處理與調(diào)用；WS-Security、WS-Transactions和WS-Coordination等標(biāo)準(zhǔn)提供了上下文信息與對話狀態(tài)管理

相對RESTful而言，SOAP協(xié)議屬于復(fù)雜的、重量級的協(xié)議
REST是一種輕量級的Web Service架構(gòu)風(fēng)格，其實現(xiàn)和操作比SOAP和XML-RPC更為簡潔，可以完全通過HTTP協(xié)議實現(xiàn)，還可以利用緩存Cache來提高響應(yīng)速度，性能、效率和易用性上都優(yōu)于SOAP協(xié)議。REST架構(gòu)對資源的操作包括獲取、創(chuàng)建、修改和刪除資源的操作正好對應(yīng)HTTP協(xié)議提供的GET、POST、PUT和DELETE方法，這種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST架構(gòu)尤其適用于完全無狀態(tài)的CRUD（Create、Read、Update、Delete，創(chuàng)建、讀取、更新、刪除）操作。

區(qū)別

核心：在SOAP模式把HTTP作為一種通信協(xié)議，而不是應(yīng)用協(xié)議。所以http中的表頭，錯誤信息等全部無視。實際上http有 put get post delete等方法。
REST 則不然，HTTP method中的 POST GET PUT DELETE 都是與請求方法對應(yīng)的，rest真正實現(xiàn)了http的五層結(jié)構(gòu)。
REST 提交的請求中，代理服務(wù)器可以通過請求方式直接判斷請求動作是要進(jìn)行什么操作。
REST 輕量級，SOAP重量級；
REST 學(xué)習(xí)起來比較簡單，容易上手，SOAP相對來說難些回；
REST 能通過http形式的直接調(diào)用，基于JSON，SOAP通過XML傳輸；
REST 效率和速度來說相對快些答，SOAP則稍遜一籌

3.如何設(shè)計RESTFul風(fēng)格API（動物園為例）

設(shè)計

1.資源路徑（URI）

在RESTful架構(gòu)中，每個網(wǎng)址代表一種資源（resource），所以網(wǎng)址中不能有動詞，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫的表名對應(yīng)，一般來說，數(shù)據(jù)庫中的表都是同種記錄的”集合”（collection），所以API中的名詞也應(yīng)該使用復(fù)數(shù)。

有一個API提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應(yīng)該設(shè)計成下面這樣。

   https://api.example.com/v1/zoos
   https://api.example.com/v1/animals
   https://api.example.com/v1/employees

2.HTTP動詞

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

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

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

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

HEAD：獲取資源的元數(shù)據(jù)。
OPTIONS：獲取信息，關(guān)于資源的哪些屬性是客戶端可以改變的。

下面是一些例子。

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：刪除某個指定動物園的指定動物

3.過濾信息（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é)果按照哪個屬性排序，以及排序順序。

?animal_type_id=1：指定篩選條件

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

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

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

200 OK - [GET]：服務(wù)器成功返回用戶請求的數(shù)據(jù)，該操作是冪等的（Idempotent）。

201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數(shù)據(jù)成功。

202 Accepted - [*]：表示一個請求已經(jīng)進(jìn)入后臺排隊（異步任務(wù)）

204 NO CONTENT - [DELETE]：用戶刪除數(shù)據(jù)成功。

400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發(fā)出的請求有錯誤，服務(wù)器沒有進(jìn)行新建或修改數(shù)據(jù)的操作，該操作是冪等的。

401 Unauthorized - [*]：表示用戶沒有權(quán)限（令牌、用戶名、密碼錯誤）。

403 Forbidden - [*] 表示用戶得到授權(quán)（與401錯誤相對），但是訪問是被禁止的。

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)建一個對象時，發(fā)生一個驗證錯誤。

500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯誤，用戶將無法判斷發(fā)出的請求是否成功。

狀態(tài)碼的完全列表參見這里。

5.錯誤處理（Error handling）

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

{
    error: "Invalid API key"
}

6.返回結(jié)果

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

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

4.REST風(fēng)格的接口測試流程

接口測試有稱為API測試，接口測試是測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。測試的重點是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。