RESTful API設計風格
RESTful API是一種設計風格，設計模式，並不是標準，它可以讓程式語言的API更加易於使用和維護。
主要是把每個網址當做資源Resource來看，針對同一個資源做不同的HTTP方法之後，會得到不同的結果
假設今天要獲取使用者的資料
URL可能會寫成
/users_get/1
/get_users/1
/get_userList
/reach_userList
/get_userAll
/reach_userAll
每一個人寫得都不同，API很混亂不一致，難以理解功能，不知道那URL是幹嘛的，搞不好過一陣子當初寫的人都不知道是什麼意思
因此，我們可以借助RESTful的理念，無論是哪位開發者，可以有個統一的規範
可以改寫成以下
獲取全部使用者資料 /GET /users
獲取使用者id為1的資料 /GET /users/1
設計RESTful API的基本原則:
1. 使用合適的HTTP方法：使用HTTP方法來表示操作類型
- GET: 用於從伺服器獲取資源
- POST: 用於在伺服器上新增資源
- DELETE: 用於刪除現有的資源
- PUT / PATCH: 用於更新現有的資源
這邊以Ruby on rails舉例
| HTTP方法 | 路徑 | Controller | Action | 說明 |
|---|---|---|---|---|
| GET | /users | UserController | index | 使用者列表 |
| POST | /users | UserController | create | 新增使用者 |
| GET | /users/new | UserController | new | 新增使用者的頁面 |
| GET | /users/:id/edit | UserController | edit | 編輯使用者的頁面 |
| GET | /users/:id | UserController | show | 檢視單一使用者 |
| PATCH | /users/:id | UserController | update | 更新單一使用者 |
| PUT | /users/:id | UserController | update | 更新單一使用者 |
| DELETE | /users/:id | UserController | destroy | 刪除單一使用者 |
2. 使用清晰的URI：URI應該具有可讀性，並且應該反映資源的層次結構。
3. 使用名詞而不是動詞：URI中應該包含資源名詞，而不是動詞；例如，使用/users表示使用者資源
不要使用以下命名
- /getUsers
- /createUser
- /updateUser
- /deleteUser
4. 支援多種數據格式：RESTful API應該支援多種數據格式，如JSON和XML，以滿足不同客戶端的需求。
5. 使用狀態碼：使用HTTP狀態碼來表示操作的結果，例如200 表示OK成功、404 Not Found表示資源不存在、500 表示伺服器錯誤等。
優點:
- HTTP方法以及資源Resource兩者切割分離，確保明確的操作行為，降低複雜度
- 每個 API 專注做一件事，提高各種組合的可能性
缺點:
- 若一次需要操作多個資源Resource，還是得乖乖發送多個Request，效能方面較差
- 網路上所有東西都是資源，將資源名詞抽象化其實不容易。定義正確資源名詞的URI，並使用HTTP方法去操作它
資源」為主體，透過API去操作資源時，一次就是針對一個資源，如果有什麼複雜的需求，就是要多發幾次 request 才能辦到，聽起來雖然很麻煩很像缺點，但如果是開放給第三方串接的 API，大多時候你是不知道別人會怎樣使用你的資料，既然都不知道，那一次一個資源為單位的Request，其實是非常明確切分的，反正要怎麼組合這些資料，是串接者自己的事情了。