API 與 RESTful
API 的用途
API 雖然背後涉及了很多網路請求的細節，但要簡單地說就是資料交換的方式。
服務上線前會有很多原始資料要整理，這些資料不會總是存在 js 檔裡面，
所以原始資料通常會交給後端的伺服器管理，瀏覽器發出請求後才會去取這些資料。
可以運行伺服器的語言也有百百種，有 C#、PHP、Ruby 等，
所以瀏覽器與伺服器溝通的會採用雙方都能解析的格式，
資料內容早期可能會有純文字或 XML 等等，
現今通常以 JSON 格式呈現，最後傳回前端渲染在畫面上。
RESTful
REST 是一種網路程式的設計風格，主要有六種重要的指標：
- 客戶端-伺服器端：將前後端的程式系統完全分開，方便兩端的管理、擴充、維護。
- 無狀態：客戶端的請求每次都是獨立的，每次請求都會得到包含必要資訊的回應。比如按電鈴，按幾次就會響幾次，每次的行為都是獨立的。
- 快取：保留某些請求行為和資源，有效期限內客戶端如果發起一樣的請求，可以直接在中間伺服器給出快取的資料，不用每次都與真正的伺服器請求，節省伺服器負載。
- 統一介面：統一請求的方式，包含路由的寫法、要帶什麼 id 或授權、資料的詳細格式等。
- 分層系統：前後端中間通常會再安排代理伺服器，用來處理快取、身份驗證、資安等等的業務邏輯，減少直接訪問後端伺服器造成的流量消耗和危險性。
- 按需代碼（可選）：根據特定的請求從後端生成程式碼，再發送到前端執行。
RESTful API 就是建立在以上的概念所設計出來的網路請求架構，
規定使用者透過網址（URL）發送過來的請求，來對應伺服器要做的事，
所以這時候路由的設計方式就很重要，也就是上面說的統一介面的問題。
前後端的開發人員會規劃出一套完整的路由架構，讓雙方可以看懂請求的行為是什麼，
比如將留言板網站的網域是 www.example.comments.com，
前端會根據畫面的按鈕、表單、超連結等等的互動行為，
把使用者想做的事透過 URL 發送過來讓後端接收，
因此路由可能會這樣設計：
| URL | HTTP method | Definition |
|---|---|---|
| /user/:id | GET | 查看某個使用者的資料 |
| /user/:id/comments | GET | 查看某個使用者的留言 |
| /user/:id/add | POST | 在某個使用者的頁面留言 |
| /user/:id/comments/:id/update | PUT | 更新某一則留言 |
| /user/:id/comments/:id | DELETE | 刪除某一則留言 |
網址會因為使用者的各種行為產生頁面跳轉而改變， 改變的方式就會依照上面設計好的路由去寫， 如：
www.example.comments.com/user/123456www.example.comments.com/user/123456/add
一般網站大多是這樣設計的，因此網址列經常會看到類似的結構！