一、什么是RESTful
1.1來源
REST這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。Roy Fielding是 HTTP 規(guī)范的主要編寫者之一、Apache服務(wù)器軟件的作者之一、Apache基金會的第一任主席。
1.2名稱解釋
REST，即Resource Representational State Transfer的縮寫。意思是：“表現(xiàn)層狀態(tài)轉(zhuǎn)移”。
Resource：資源，即"數(shù)據(jù)",你可以用一個URI（統(tǒng)一資源定位符）指向它，每種資源對應(yīng)一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符；
Representational：某種表現(xiàn)形式--"資源"具體呈現(xiàn)出來的形式，比如用JSON，XML，JPEG等；
State Transfer：狀態(tài)變化。通過HTTP動詞實現(xiàn)（GET、POST、PUT、DELETE等）?；ヂ?lián)網(wǎng)通信協(xié)議HTTP協(xié)議，是一個無狀態(tài)協(xié)議。這意味著，所有的狀態(tài)都保存在服務(wù)器端。因此，如果客戶端想要操作服務(wù)器，必須通過某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）。而這種轉(zhuǎn)化是建立在表現(xiàn)層之上的，所以就是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
RESTful API就是REST風(fēng)格的接口，RESTful是一種軟件架構(gòu)風(fēng)格，而不是標(biāo)準(zhǔn)。
二、REST和SOAP的區(qū)別
2.1什么是SOAP
SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴格定義的信息交換協(xié)議，用于在Web Service中把遠程調(diào)用和返回封裝成機器可讀的格式化數(shù)據(jù)。事實上SOAP數(shù)據(jù)使用XML數(shù)據(jù)格式，定義了一整套復(fù)雜的標(biāo)簽，以描述調(diào)用的遠程過程、參數(shù)、返回值和出錯信息等等?？偟膩碚f，它是交換數(shù)據(jù)的一種規(guī)范，是一種輕量級的、簡單的、基于xml的協(xié)議。
2.2兩者區(qū)別
1.安全性：SOAP優(yōu)于REST
2.效率和易用性：REST更勝一籌
3.成熟度：SOAP優(yōu)于REST
4.REST是一種風(fēng)格，而SOAP是一種協(xié)議
三、設(shè)計RESTful風(fēng)格API
3.1、通信協(xié)議
采用Http協(xié)議，對于資源的具體操作類型，常用的HTTP動詞有下面五個：
GET：從服務(wù)器取出資源（一項或多項）。
POST：在服務(wù)器新建一個資源。
PUT：在服務(wù)器更新資源（客戶端提供改變后的完整資源）。
PATCH：在服務(wù)器更新資源（客戶端提供改變的屬性）。
DELETE：從服務(wù)器刪除資源。
3.2、用 URL 定位資源
REST 的主體是資源，所謂“資源”，即數(shù)據(jù)，就是網(wǎng)絡(luò)上的一個具體信息，例如：一張圖片，一段文字、一種服務(wù)，所以網(wǎng)址中不能有動詞，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫的表格名對應(yīng)?？傊褪且粋€實際存在的東西，而 URL 就是用來指向這個資源的。
舉例來說，有一個API提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應(yīng)該設(shè)計成下面這樣。
https://api.example.com/zoos
https://api.example.com/animals
https://api.example.com/employees
3.3、用 HTTP 動詞描述操作
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：刪除某個指定動物園的指定動物
四、RESTful 的其他細節(jié)
4.1、命名規(guī)則
- 全部小寫，用 _ 或 - 線連接。(之所以不用駝峰命名法，是因為早期的 URI 一般都是表示服務(wù)器上的文件路徑，而不同服務(wù)器對大小寫的敏感性是不同的，為了兼容不同服務(wù)器所以才規(guī)定不能混用大小寫字母。)
- URL 中只用名詞指定資源，因為 REST 的核心是資源，而表示資源的詞語天然就是名詞。
- 資源用復(fù)數(shù)表示。
4.2、版本
一種方法是在 URL 中添加版本號，例如：
https://api.example.com/v1/zoos
另一種方法是將版本號加在 HTTP 請求頭信息的 Accept 字段中，例如：
Accept: version=1.0
網(wǎng)上能找到的版本號加在 URL 中的例子，都是如我上例所示的寫法。但是 Jack_Zeng 指出，這樣寫容易有歧義，會讓人誤以為 v1 也是資源的一部分，一般都是這么寫：
https://api.example.com/zoos?api-version=1
五、RESTful接口測試
專業(yè)的測試步驟:
5.1、測試的方法(列舉其中兩種)
1.采用Postman測試工具
2.采用swagger（不做介紹）
5.1.1、Postman的主要功能
- 可以模擬各種HTTP 請求
- Collection 功能（測試集合）
- 人性化的Response整理
- 內(nèi)置測試腳本語言
- 設(shè)定變量與環(huán)境
5.1.2、HTTP Header
Accept: 指定客戶端能夠接收的內(nèi)容類型
Accept-Charset: 瀏覽器可以接收的字符編碼集
Authorization: HTTP授權(quán)證書
Content-Type: 請求的與實體對應(yīng)的MIME信息
Referer: 先前的網(wǎng)頁的地址，當(dāng)前請求網(wǎng)頁緊隨其后，及來路
5.2、編寫測試計劃
了解完接口的格式之后，根據(jù)項目中的業(yè)務(wù)需求編寫測試計劃?，F(xiàn)在有一個業(yè)務(wù)需求:
GET : http://localhost:8080/api/users/list
header : Content-Type = application/json
body : 空
Response : 返回所有User對象
Status code : 200
測試計劃：
實行的測試用例分為兩種：
正向的測試用例 : 返回所有對象
負向的測試用例 : URL輸入不正確
5.3、使用Postman進行用例的測試
正向測試用例：
在Tests里寫下驗證測試結(jié)果信息：
正向測試用例的返回結(jié)果:
負向測試用例：
修改為錯誤路徑 http://localhost:8080/api/users/info
負向測試用例的返回結(jié)果:
相關(guān)教程
https://www.imooc.com/learn/811
https://www.imooc.com/learn/1048
