【API】後端測試API
API（Application Programming Interface，應用程式介面）
REST，即Representational State Transfer的縮寫,中文是"表現層狀態轉化"。
它是一種網際網路應用程式的API設計理念：可以用URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作來解釋什麼是REST。
其實全稱是 Resource Representational State Transfer：通俗來講就是：資源在網路中以某種表現形式進行狀態轉移。(再通俗來說，就是通過HTTP請求伺服器上的某資源，使該資源copy了一份到服務請求方那去了(get動作)。個人這麼理解)
我們分解開來進行解釋：
- Resource：資源，即資料它可以是一段文字、一張圖片、一首歌曲等；
- Representational：某種表現形式，比如用JSON，XML，JPEG等；HTTP請求的頭資訊中用Accept和Content-Type欄位指定，這兩個欄位才是對"表現形式"的描述。
- State Transfer：狀態變化。通過HTTP動詞實現。
注：網際網路通訊協議HTTP協議，是一個無狀態協議。**這意味著，所有的狀態都儲存在伺服器端。**因此，如果客戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀態轉化"（State Transfer）。HTTP協議裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
- REST的設計原則
- 網路上的所有事物都被抽象為資源
- 每個資源都有一個唯一的資源識別符號
- 同一個資源具有多種表現形式(xml,json等)
- 對資源的各種操作不會改變資源識別符號
- 所有的操作都是無狀態的
-
HTTP協議-URL
HTTP是一個屬於應用層的協議，特點是簡捷、快速。
schema：//host[:port]/path[?quert-string] [#anchor]
-
schema 指定底層使用的協議（例如：http，https,ftp）
-
host 伺服器的IP地址或者域名
-
port 伺服器埠，預設為80
-
path 訪問資源的路徑
-
query0string 傳送給http伺服器的資料
-
anchor 錨
-
HTTP協議-請求
HTTP協議-請求
組成格式：請求行、訊息報頭、請求正文
請求行
格式如下：Method Request-URI HTTP-Version CRLF
舉例
GET / HTTP / 1.1 CRLF
請求方法
- GET 請求獲取Request-URI所標識的資源
- POST 在Request-URI所標識的資源後附加新的資料
- HEAD 請求獲取由Request-URI所標識的資源的響應訊息
獲取
傳送資料
- PUT 請求伺服器儲存一個資源 ，並用Request-URI作為其標識
- DELETE 請求伺服器刪除Request-URI所標識的資源
- OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求
HTTP協議-響應
HTTP協議-響應
組成格式：狀態行、訊息報頭、響應正文
狀態行
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP/1.1 200 OK
常用狀態碼
-
200 OK //客戶端請求成功
-
400 Bad Request //客戶端請求有語法錯誤，不能被伺服器所理解
-
401 Unauthorized //伺服器收到請求，但是拒絕提供服務
-
404 Not Found //請求資源不存在
5xx伺服器錯誤
- 500 Internal Server Error //伺服器發生不可預期的錯誤
- 503 Server Unavailable //伺服器當前不能處理客戶端的請求
RESTful架構與其他架構的區別
SOAP WebService
WebService是一種跨程式語言和跨作業系統平臺的遠端呼叫技術
WebService通過HTTP協議傳送請求和接受結果時採用XML格式封裝，並增加了一些特定的HTTP訊息頭，這些特定的HTTP訊息頭和XML內容格式就是SOAP協議。
WebService 、SOAP協議、RESTful架構與WebService
RESTful架構與其他架構的區別
效率和易用性
SOAP由於各種需求不斷擴充本身協議的內容，導致在SOAP處理方面的效能有所下降。同時在易用性方面以及學習成本上也有所增加。
RESTful由於其面向資源介面設計以及操作抽象簡化了開發者的不良設計,同時也最大限度的利用了Http最初的應用協議設計理念。
安全性
RESTful對於資源型服務介面來說很合適,同時特別適合對於效
率要求很高,但是對於安全要求不高的場景。
SOAP的成熟性可以給需要提供給多開發語言的, 對於安全性
要求較高的介面設計帶來便利。所以覺得純粹說什麼設計模
式將會佔據主導地位沒有什麼意義,關鍵還是看應用場景。
restful適合做什麼開發
介面或者應用
4、 如何使用Restful
如何設計RESTful API
-
資源路徑（URI）
-
HTTP動詞
-
過濾資訊
-
狀態碼
-
錯誤處理
-
返回結果
請求設計規範
- URI使用名詞，儘量用複數，如/users
- URI使用巢狀表示關聯關係，如 /users/12/repos/5
- 使用正確的HTTP方法，如GET/POST/PUT/DELETE
- 不符合CRUD的情況：POST/action/子資源
資源路徑
在RESTful架構中，每個網址代表一種資源，所以網址中不能有動詞，只能有名詞，一般來說API中的名詞應該使用複數。goods、users等。
舉例
舉例來說,有一個API提供動物園( zoo )的資訊,還包括各種動物和僱員的資訊。則它的路徑應該設計成下面這樣。
https://api.example.com/v1/zoos//動物園資源
https://api.example.com/v1/animals//動物園資源
https://api.example.com/v1/employees//動物園資源
v1版本、http請求頭中 或者 名詞複數
獲取一個動物 animals/id=1
資源的設計
http 動詞 四種操作 建立 更新 讀取 刪除
HTTP動詞
對於資源的操作（CURD），由HTTP動詞（謂詞）表示
-
GET：從伺服器取出資源（一項或多項）。
-
POST：在伺服器新建一個資源。
-
PUT：在伺服器更新資源（客戶端提供改變後的完整資源）
-
PATCH：在伺服器更新資源（客戶端提供改變的屬性）。
-
DELETE：從伺服器刪除資源。
put更新資源 patch只會返回更新的資料 比如改密碼 密碼變了就返回密碼。
舉例
-
POST /zoos:新建一個動物園
-
GET /zoos/ID:獲取某個指定動物園的資訊
-
PUT /zoos/ID: 更新某個指定動物園的資訊
-
DELETE /zoos/ID:刪除某個動物園
刪除動物園，動物園裡的動物都刪除
POST新建 GET 獲取 PUT 更新 DELETE 刪除
狀態碼
標準的
伺服器向用戶返回的狀態碼和提示資訊，使用標準HTTP狀態碼。
- 200 OK 伺服器成功返回使用者請求的資料，該操作是冪等的。
- 201 CREATED created 新建或修改資料成功
- 204 NO CONTENT 刪除資料成功
200 OK
201新建修改204刪除，用得比較少的。
- 400 BAD REQUEST request 使用者發出的請求有錯誤，該操作是冪等的。
- 401 Unauthorized 表示使用者沒有認證，無法進行當前操作。
- 403 Forbidden 表示使用者訪問是被禁止的。
客戶端的請求有問題
401 沒有認證
403 提供了 但引數不足 或者許可權不夠
- 422 Unprocesable Entity 當建立一個物件時，發生一個驗證錯誤。
- 500 INTERNAL SERVER ERROR internal server error 伺服器發生錯誤，使用者將無法判斷髮出的請求是否成功。
422
驗證錯誤 後端需要使用者名稱 密碼 前端只提供了一個使用者名稱 錯誤了 密碼不能為空
500
伺服器錯誤
錯誤處理
422 引數錯誤 500