iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 3
1

先強調一下! 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 首頁需要的資料全部寫在這裡

看了眼花撩亂,說老實的我一個禮拜回去看我就已經有點看不出來是什麼功能了!簡單來說就是沒有一個原則。

例如上面的

  1. GET /postList?id=2
  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

這樣規劃有個好處,看網址就可以知道怎麼找資料,需要抓資料時,就可以比較容易判斷,不會像前面所敘述的,忘記有什麼方法或是不知道那個功能裡面怎麼寫的,日後別人接手也比較好維護。

參考

此篇文章同步發到個人部落格


上一篇
安裝Laravel
下一篇
規劃系統核心目的
系列文
使用 Laravel 打造 RESTful API30

尚未有邦友留言

立即登入留言