前後端分離的架構在現在大型系統的開發已經是必備的，因為要將邏輯分離，這樣在開發的時候才不會耦合性太高，然而此種架構最常見的後端開發方式就是設計成 RESTful 拉，因此今天就讓我們來聊聊REST吧！

先備知識

• 需要先理解 web 的基礎原理，可以到本系列文的 Day3 查看

REST

什麼是 REST

REST 是由 Roy Fielding 博士在 2000 所發表的 Architectural Styles and the Design of Network-based Software Architectures 論文中所中提到的一種 網頁服務設計風格，基本上就是 Representational State Transfer 的縮寫，代表意義如下

Representational

必須是可被描述的一種實體，例如 json、xml 等

State Transfer

如字面上的意義，就是一種 狀態轉換，基本上就是對應到 http method 如 Get、POST 等

什麼是 RESTful

只要是使用 REST 的概念所設計的系統皆可以稱之為 RESTful 的系統，為什麼後面會多了 ful 呢，舉例而言，漂亮的單字叫做 Beauty，代表漂亮的東西就使用 Beautiful 來代表，因此，使用 REST 所設計的系統就叫做 RESTful了

REST 設計上有什麼限制

客戶端-伺服器（Client-Server）

也就是今天最早提到的 前後端分離 的概念，將使用者操作時所關注的邏輯 與 資料處理
時所關注的邏輯進行分離，有助於提高使用者介面的跨平台的可移植性.通過簡化伺服器模組也有助於伺服器模組的可延伸性。

無狀態（Stateless）

Server 端不會儲存任何 Client 的資料，因此在 Client 端每次進行資源存取時都必須要包含所有的必須的狀態資訊，一般而言都會將資訊儲存於 header 中。

快取（Cacheability）

將 Server 端所提供的資源狀態進行快取，這樣的做法不但可以加快 Client 存取資料的速度，也可以減少 Client 對於 Server 端的存取，將整體的資源消耗程度降低。

統一介面（Uniform Interface）

也就是在做資源存取時的統一規範，以下有四項限制

1. request 中包含資源的 ID
   一般來說資源的 id 通常都為資料庫裡的 primary key
2. 資源通過標識來操作
   呼應第一點所說，要對資源進行 CRUD 時必須使用唯一識別標示，這樣 Server 才會知道要對誰進行處理
3. 訊息的自我描述性
   每一個訊息都包含足夠的資訊來描述如何來處理這個資訊
4. 用超媒體驅動應用狀態
   client 在存取資源後可以得知資源包含何種動作，也就是提供動態連結，例如
   應用 A 有 user 與 app 兩個模組，client 在存取 url 為 /api/v1 後，應用 A 回傳

   {
       "version": "v1",
       "resources: [
           "/api/v1/user",
           "/api/v1/app"
       ]
   }
   

URL 設計

REST 風格的 URL 基本上設計的格式如下

prefix + endpoint

prefix

prefix 一般而言我都是由以下資訊拼湊而成

1. 因為是 API 所以理所當然為 /api
2. 識別 API 的版本因此加入 /v{number} 格式，如 /v1 為第一版本的 api

endpoint

資源存取的終點，如要操作編號為 123 的 user，endpoint 就為 /user/123

如果要操作 版本 1、user 編號為 123 的 API，整體的 URL 會像是

/api/v1/user/123

REST 有什麼優點

使用 REST 作為網頁服務的開發架構具有以下幾種優點

• 可更高效利用快取來提高回應速度
• 通訊本身的無狀態性可以讓不同的 Server 的處理一系列請求中的不同請求，提高 Server 的擴充性
• 相對於其他疊加在HTTP協定之上的機制，使用 REST 所設計的軟體ㄑ 相依性 更小
• 不需要額外的資源發現機制
• 在軟體技術演進中的長期的相容性更好

實際案例

背景

今天我們開發了一個會員系統，其中我們要負責將 user 設計成一個具有 REST 風格的 API

資料設計

首先我們將 user 進行，每個使用者都必須要有一個唯一的會員編號，架構如下

type User struct {
	ID       string `json:"id"`
	Username string `json:"username"`
	Password string `json:"password"`
	Email    string `json:"email"`
	Phone    string `json:"phone"`
}

RESTful API 設計

對 user 進行 CRUD，URL 設計如下

• 取得 user 列表：GET /api/v1/user
• 取得單一 user：GET /api/v1/user/:id
• 建立 user：POST /api/v1/user
• 取代 user：PUT /api/v1/user/:id
• 修改 user：PATCH /api/v1/user/:id
• 刪除 user：DELETE /api/v1/user/:id

小結

REST 的設計真的可以讓我們對於資源的掌控度與靈活度更高，也同時讓我們審視自己在設計軟體架構是否有問題，真的是一個不錯的設計，推薦給大家！

參考

• https://medium.com/@cindyliu923/%E4%BB%80%E9%BA%BC%E6%98%AF-rest-restful-7667b3054371
• https://tw.twincl.com/programming/*641y
• https://docs.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
• https://charder.readbook.tw/api-design/restful/