RESTful網上有很多解釋，現在看來其實挺簡單的。它本身就是一種風格，不遵守也沒啥，但這么多人都愿意遵守這種風格。也是自然有其原有的。
1.非RESTful實例和RESTful風格的寫法對比
比如我們在沒有遵守RESTful風格前，按照我的習慣要寫一個員工的增刪查改大概會這樣寫：
http://localhost:8080/employee/get/{id} GET
http://localhost:8080/employee/delete/{id} POST/GET
http://localhost:8080/employee/create POST
http://localhost:8080/empliyee/update POST
基于RESTful風格的寫法我大概會這樣：
http://localhost:8080/employee/{id} GET
http://localhost:8080/employee DELETE
http://localhost:8080/employee POST
http://localhost:8080/empliyee PUT
如果遵循現在更細的寫法可能還會多一種（不細分可歸屬到PUT下，其實這樣說不對的冪等性不一樣）
http://localhost:8080/empliyee/salt PATCH
首先，風格這玩意不好去硬性要求，但大神們都這么玩。就我目前使用而言，沒有使用RESTful風格前，請求路徑中需要很多的動詞和名稱結合著去描述這個請求的具體行為。RESTful則不需要這些動詞描述，只需要名詞，和規定的請求方式來描述，最直觀的表現就是url短了，當然好處應該不止如此，其實就是整體一致性，更少的描述詞匯，更準確的直觀快速的描述，這點對我而言是在面對一堆自由風格的個性請求時才真的有體會到的。
2.GET|DELETE|POST|PUT|PATCH的使用
關于他們的使用，首先要說一個點，就是操作的影響，網上也有說對資源的操作等專業的說法。我理解就是真正的影響，影響可以用數據庫相關的概念來類比，如增刪改查。
查 影響：土一點說除了讓你看到啥影響也沒有，查一萬次也是如此。
增 影響：確實是多了一條數據或者多條數據，原來沒有，從無到有。即使數據庫有唯一校驗，相同手機號的人，不可能再被創建，但從影響上來說，他是確確實實是增。
改 影響：原來就有，但是對原有的景象修改。（細分可分為改具體的，或者整個對象，比如改一個員工全部的屬性，或者只改密碼的接口）
刪 影響：刪除原來就有的，如果軟刪其實改，但是前端真的看不到了，也可放到刪里。
| 請求方式 | 冪等 | 安全 | 操作 |
|---|---|---|---|
| GET | 是 | 是 | 查 |
| POST | 否 | 否 | 增 |
| DELETE | 是 | 否 | 刪 |
| PUT | 是 | 否 | 改 |
冪等：可以理解執行一次和多次影響和第一次一樣的。
安全：是否改變了數據，沒改變數據就是安全的。
解釋起來是這樣的，修改一個員工的密碼的接口。他是操作里的改操作，這個操作執行n次的結果都是一樣的。當然這個用PUT是完全可以的，如果確實能描述的清楚，是局部的修改，PATCH更為準確。雖然我目前沒怎么用，但是解釋起來是合理可行的。所以，大環境使用的話，PATCH也還是可以很快適應的。
PS：我對于RESTful的理解目前是這樣的，大多也是看帖子，加自己項目中實踐意淫出來的。想一想覺得能解釋的通，就認為自己差不多是理解對了。所以有錯誤的地方，歡迎批評指正。
