先強調一下！ RESTful API 是一個設計模式，不一定每個需求都會符合這樣的設計，所以還是需要依照專案的需求去做一點調整才不會感覺為了用RESTful API而用RESTful API。
第一次開發網站的我
小時候的我(誤)兩年前，設計網站的時候，基本上用ajax拿資料時，我的後端URI命名方式都是很隨意的例如像這樣，以post（文章）資源當範例
- GET /getPost
- GET /postList?id=2
- GET /getAllPost <-跟上面那個差在哪?
- POST /addPost
- POST /post/deleteAll
- POST /post/delete?id=87
甚至會依照前端的畫面，打造專屬的命名 URI
- GET /ajax/index/view <-把所有 index 首頁需要的資料全部寫在這裡
看了眼花撩亂，說老實的我一個禮拜回去看我就已經有點看不出來是什麼功能了！簡單來說就是沒有一個原則。
例如上面的
- GET /postList?id=2
- GET /getAllPost
第一個網址可能有分頁的功能，第二個可能只有讀首頁需要的所有Post 文章資料而已，很難知道這個URI的功能。
如果工作的時程比較短，緊急又壓縮到我做其他事的時間，我乾脆直接做一個新的，所以變得越來越多方法！
想一想這樣不行，也剛好目前手上的案子，進入維護階段，讓我開始想盡任何的辦法優化系統，其中一樣就是打造一組RESTful API。
RESTful API 是什麼東西呢？！
RESTful API是一種設計模式
- 定義一組「物件」(Object) 它們是可以被操作！
- 物件運用一組固定「動作」(Action) 簡稱（CRUD)
- 創建(Create)
- 刪除(Delete)
- 更新(Update)
- 讀取(Read)
- 主流以 JSON 格式做資料傳遞
基本上會包含 URI \ Object \ Action
常用 HTTP 動詞
HTTP 定義了一組能令給定資源，執行特定操作的請求方法（request methods）。
- GET: 讀取資源
- POST: 新增資料 (我覺得它屬於萬用)
- DELETE: 刪除資源
- PUT: 替換資源
- PATCH: 更新資源
改寫上方很混亂範例
以 Post(文章) 這個物件舉例
| HTTP 動詞 | URI | 功能 | 說明 |
|---|---|---|---|
| POST | api/v1/posts | 發表一篇文章 | 如果相同請求送第二次，會回傳新的一筆資料，內容一樣只有ID不同。 |
| DELETE | api/v1/posts/1 | 刪除ID1 文章 | 如果發送兩次請求，第二次回傳找不到資源的錯誤訊息。 |
| PUT | api/v1/posts/1 | ID1資料整筆替換 | 替換 ID1 整筆資料，有點像舊資料的刪除，寫入新的資料。 |
| PATCH | api/v1/posts/1 | 更新文件 ID1 部分內容 | 指替代掉部分內容，內容會依照發送請求的資料修改。如果沒有填寫的部分保留舊的資料內容。 |
其他不符合以上類別的動作用 POST
這樣規劃有個好處，看網址就可以知道怎麼找資料，需要抓資料時，就可以比較容易判斷，不會像前面所敘述的，忘記有什麼方法或是不知道那個功能裡面怎麼寫的，日後別人接手也比較好維護。
