RESTFUL風格架構
WYH?
隨著前后端分離的流行，以及移動互聯網的爆發，導致后端API介面要向不同的Web端提供服務，那么對于 API 的規范就需要有一定的要求了，這個時候 RESTFul 的優勢就體現出來了，它更簡潔，更有層次，更易于實作快取，
此概念"表現層狀態轉換(Representational State Transfer&REST)"是Roy Thomas Fielding 博士于 2000 年在他的博士論文中提出來的一種萬維網軟體架構風格，目的是便于不同軟體/程式在網路（例如互聯網）中互相傳遞資訊，表現層狀態轉換是根基于超文本傳輸協議 ( HTTP ) 之上而確定的一組約束和屬性，是一種設計提供萬維網路服務的軟體構建風格，
——維基百科
核心思想
其實REST就是對資源表現形式的轉換的一種規范，或者說是資源以某種形式進行狀態轉換，直白的講就是按照一定的規范去操作某種特定格式的資料，
規范
- 用URI定位資源
- URI由名稱組成
- 使用HTTP方法對應資料的操作
HTTP請求方法主要有七種：分別是：
GET, POST 和 HEAD方法（HTTP1.0）
OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法（HTTP1.1）
其中GET、POST 、DELETE、PUT四種請求方法在RESTFUL風格中最為常見：
| HTTP方法 | 安全性 | 冪等性 | 介面說明 |
|---|---|---|---|
| GET | 安全 | 冪等 | 獲取資源（Read） |
| POST | 不安全 | 非冪等 | 創建資源（Create） |
| PUT | 不安全 | 冪等 | 更新資源（Update） |
| DELETE | 不安全 | 冪等 | 洗掉資源（Delete） |
關于URL&URI
你可能會注意到，上面提到的REST規范中，用到的是URI而不是URL，那它們之間有什么區別呢？其實，要想弄清楚，還需要引入另一個概念——URN，
三者解釋：
- URI：Universal Resource Identifier 統一資源標志符
- URL：Universal Resource Locator 統一資源定位符
- URN：Universal Resource Name 統一資源名稱
一張圖說明三者的關系：
可以看出，URI包含URL與URN，或者說是URL與URN的總稱，
所以：只要一個URI符合URN，我們就可以認為這個URI不是URL了，其實，關于URL與URN，大白話就是，URL可以在任意的互聯網中定位一個資源，而URN則辦不到，
url. https://www.google.com
urn. mailto:[email protected]
關于冪等性&安全性
你也許也會注意到上文提到了冪等性與安全性的概念，在這里不做過多解釋，就按照大白話簡單說明下：
- 冪等性：當一個請求與多個同樣的請求會不會有相同的結果
- 安全性：一個請求發出之后會不會對服務器資源產生改變
額外：常用HTTP回應碼
| 代碼 | 含義 |
|---|---|
| 200 | （OK）- 如果現有資源已被更改 |
| 201 | （created）- 如果新資源被創建 |
| 202 | （accepted）- 已接受處理請求但尚未完成（異步處理） |
| 301 | （Moved Permanently）- 資源的URI被更新 |
| 303 | （See Other）- 其他（如，負載均衡） |
| 400 | （bad request）- 指代壞請求 |
| 404 | （not found）- 資源不存在 |
| 406 | （not acceptable）- 服務端不支持所需表示 |
| 409 | （conflict）- 通用沖突 |
| 412 | （Precondition Failed）- 前置條件失敗（如執行條件更新時的沖突） |
| 415 | （unsupported media type）- 接受到的表示不受支持 |
| 500 | （internal server error）- 通用錯誤回應 |
| 503 | （Service Unavailable）- 服務當前無法處理請求 |
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/165061.html
標籤：Java
上一篇：力扣題解 - 739. 每日溫度
下一篇：Java并發相關知識點梳理和研究