哈囉～大家好！
今天主要是來看看 To-do List API 有沒有符合 RESTful API 的設計規範。
📌 如果想再看看 API 比較詳細的內容解釋，可以參考 Day 8 唷！

RESTful API 是什麼呢？

指的是遵從 REST 規則設計的 Web API，REST 的全名是 Representational State Transfer ，它是一種 架構風格，透過 HTTP 協議來傳遞前後端的資源。

它的核心概念就是：
網路上的每個東西，都是「 資源 」。透過 URL 來標示每一個資源的位置，以 GET、POST、PATCH / PUT、DELETE 方法表示如何使用資源，每一次的資源請求都需要帶包含包含所需的完整資訊（EX：Token、參數），並以 HTTP 的狀態碼回應是否請求成功。

✨ RESTful API = URL + HTTP Method ✨

因為 RESTful API 的明確設計規則，所以也具備以下優點：

1. 一致性 ：前端不用猜 API 怎麼設計，看路徑與方法就知道要做什麼。
2. 可擴展性 ：符合 HTTP 標準，容易擴充。
3. 易理解 ：透過 URL 和 HTTP Methods 就能夠理解，非常直觀。

了解 RESTful API 規則之後，再來看看昨天的 To-do List API 設計。

原先的規劃想法是，因為「 新增 」、「 查詢 」任務的時候，不需要特別針對哪一組 ID 做動作，所以就把這兩個動作的 URL 規劃成：/tasks，然後透過不同的 HTTP Methods 就可以取得想要的資訊。 然後「 修改 」、「 刪除 」任務時，則需要對某一組 ID 修改，所以在 URL 的規劃上才會用單數的：/task/:id ，來表示。

但是這樣 URL 的規劃有兩種，一個是 /task ；而另一個是 /tasks ，這樣的設計不符合 RESTful API 一致性原則，在實作上容易出錯，也比較容易搞混。

所以依照 RESTful API 原則，我就把原本的 /task/:id 調整成 /tasks/:id，這樣子整體來看也比較直觀、簡單！

To-do List API：

補充其他 RESTfu API 設計說明：

1. Microsoft：https://learn.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
2. AWS：https://aws.amazon.com/tw/what-is/restful-api/