iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 6
1
Software Development

從零開始的Laravel RESTful api系列 第 6

Day 06 : RESTful API 開發

前一篇文章雖然是在講 MVC 架構,然而三者囊括的情形是處於前後端合一的狀況,雖然 Laravel 本身遵循著 MVC 設計模式,但是根據每個工程師的程式碼撰寫習慣,仍然有可能流於 MVC 三者混雜在一起的窘境。

而 API 開發的部份則省去了 V ( view ) 的部份,變成是後端開發出接口 ( endpoint ),而這個接口僅僅呈現資料的部份,而資料的呈現方式最常見的為 JSON 格式,其他的還有像是 HTML、 XML 或者純文字格式等。設計出接口後,就是前端將這些資料加上 HTML、CSS、Javascript 等,達到前後端的程式邏輯分離的效果。

定義:

在 API 開發中,最常見的架構風格為 RESTful API,REST 為 (Re)presentational (S)tate (T)ransfer 的縮寫,而 RESTful 並非一個必須遵守的 API 開發標準,它僅僅是個架構風格,而這個架構風格盛行於許多企業的網站開發當中,RESTful API 除了將 URI 設計得更簡潔之外,另外它也善用 HTTP verb,使其能夠更直觀。

以下為 RESTful API 開發必須遵守的部份規範:

  • Client、server端分離

    將 server 端和 client 端分離開來,RESTful 風格規範 server 端呈現 API 的標準,使其能夠讓多種 client 端的平台串接,提高可擴充性。

  • Stateless

    每一個 request 都是獨立的,從 client 端發出的 request 必須具備所有必要的資訊 ( 包含 HTTP Header 具備的資訊 ),並且 每個 request 之間不會互相影響,造成互相影響的因子 ( 如:session ) 則必須由 client 端完成。

  • Cacheable

    server 端需要明確定義該 request 對應到的 response 是否為 cachable,若該 response 為 cacheable 時,第一次的 lifecycle ( request to response ) 結束後,下次從 client 端發相同的請求到 server 端時,client 端就可以直接有權利重複使用原本應該對應的 response,如此可省去一些時間。

  • URL 不可有動詞存在

    每個 URL 表達一個 resource,也就是每個可以被命名的資訊 ( 如: person、book、product 等,為了將 URI 設計得更簡潔,因此不用動詞。

  • URL 路徑的名詞最好用複數,而且最好開頭是小寫

    如此確保 URL 的格式一致

  • 每個 '/' 隔開的部份表達層級關係,而 URL 最好不要以 '/' 結尾

Endpoints:

API endpoints 為前後端之間的溝通窗口,若前端要串接 API 時,就是透過 API endpoints 取得資源。而以下就列出了一般 API 與 RESTful API 的 endpoints 差異。

general :

目的 方法 URI
取得所有使用者資料 GET /getAllUsers
新增使用者 POST /createUser
取得某位使用者資料 GET /getUser/{id}
更改某位使用者資料 POST /updateUser/{id}
刪除某位使用者 POST /deleteUser/{id}

RESTful :

目的 方法 URI
取得所有使用者資料 GET /users
新增使用者 POST /users
取得某位使用者資料 GET /users/{id}
更改某位使用者資料 PUT/PATCH /users/{id}
刪除某位使用者 DELETE /users/{id}

參考資料:

  1. What is REST : https://restfulapi.net/
  2. RESTful API 規範 : https://www.itread01.com/content/1541631243.html

上一篇
Day 05 : MVC 架構
下一篇
Day 07 : Postman
系列文
從零開始的Laravel RESTful api30

尚未有邦友留言

立即登入留言