API 是什麼?

API，全名 Application Programming Interface (應用程式介面)，簡單來說，是品牌開發出的一種接口，讓第三方可以額外開發、應用在自身的產品上的系統溝通介面。

來看個短短的、清楚直白的敘述影片：API 就是你的餐廳服務生💁

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FzvKadd9Cflc%3Ffeature%3Doembed&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DzvKadd9Cflc&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FzvKadd9Cflc%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

以實際應用的範例而言，Google Map API 就很好理解了，常常可以在各式不同的網站看見 Google Map 應用，很多都是接 Google Map API 的範例，營運考量上，有可能 API 會限制一定使用流量以內免費，超過即收費，Google map 也是如此。

點我查看 Google Maps API 收費標準

在 RESTful API 之前，要再理解一下 HTTP，HTTP 是一種協定，全名 Hypertext Transfer Protocol（超文本傳輸協定），網路世界其實就分為客戶端、伺服器端，舉例說，客戶端就是我，伺服器端就是 Yahoo，我要看 Yahoo 的首頁，我就是向 Yahoo 的伺服器端傳送了這個要求，Yahoo 再回應資源給我。為了讓要求和回應統一規範，就有了 HTTP。

舉例，假設我要吃滷味：

• 在瀏覽器輸入 Yahoo 網址，按下 enter，送出 request (跟老闆說我要切兩塊百頁豆腐)
• 伺服器收到 request 檢查該網址是否存在(老闆轉身看百頁豆腐還有沒有)
• 伺服器發 response 回來(百頁豆腐切好了)

跟老闆點餐的方式，有一定的規範跟方式，像是我一定要用講的，不可以用比的，我要說中文，不可以說英文，這就是 HTTP 協定。

如果伺服器發現網址不存在(老闆發現百頁豆腐賣完了)，就會回傳 HTTP status code 狀態碼 404：

狀態碼又會再分為下幾種：

2xx = Success（成功）
3xx = Redirect（重定向）
4xx = User error（客戶端錯誤）
5xx = Server error（伺服器端錯誤）

在 HTTP 中，會有很多種 method 做為請求的方法，常用的幾個動作分別為：GET / POST / PUT / DELETE，正好會對應到資料庫基本操作 CRUD 增刪查改。

CRUD 為 Create(新增)、Read(讀取)、Update(更新)與Delete(刪除)的縮寫

那 RESTful API 又是什麼?

先來看是誰發明的↓

REST，全名 Representational State Transfer( 表現層狀態轉移)，他是一種設計風格，RESTful 只是轉為形容詞，像是 peace 和平這名詞，轉成形容詞是 peaceful，RESTful 則形容以此規範設計的 API，稱為 RESTful API。

先用白話來說，以剛剛 API 影片中的餐廳服務生為例，如果使用一般的 API 點菜，我要加點、查看已點菜色、修改已點菜色、取消已點菜色，都需要不同的服務生替我服務，可能加點的服務生是 John、查看已點菜色是 Annie….等，RESTful API，就是讓這些動作，都可以由同一位服務生完成。

RESTful API 主要由三種元件組成：

1. Nouns 名詞：定義資源位置的 URL，每個資源在網路上都會有唯一的位置，就如每戶人家都有唯一的地址一樣。
2. Verbs 動詞：對資源要做的動作。
3. Content Types 資源呈現方式：API 資源可以以多種方式表現，最常用的是 JSON，較輕，也較好處理。

一般的 API，可能會是這樣：

獲得資料GET    /getData
新增資料POST   /createData
刪除資料DELETE /deleteData/1

不同公司，不一樣的工程師，設計的名稱都會不一樣，沒有統一的命名方式，造成在引用各家 API 時，都需要詳讀 API 文件，理解所有設計命名規則後，才可使用。

若以 RESTful API 風格開發的話：

獲得資料GET     /data
新增資料POST    /data
刪除資料DELETE  /data/1

就是用一個唯一的 URL 定位資源，將動作藏在 HTTP 的 method 裡面。

所以使用 RESTful 風格設計的 API，就有了以下幾種優點及限制：

1. 有唯一的URL表示資源位置，統一的 API 接口。(Uniform Interface)

2. 無狀態。(Stateless)

RESTful 的狀態，意即 HTTP 的請求狀態，一般 Web 服務中，Server 端和 Client 端交互的資訊，會存在 Server 端的 Session (例如：已登入狀態)，在 Client 端再次發送請求的時候，Server 端透過保存在 Server 端的 Session，去執行 request。無狀態的意思，即 Client 端自行保存狀態，在請求 Server 的時候，一併附上給 Server 端，Server 端無保存 Client 端的狀態資訊。

舉例來說，可能在用戶登錄系統時，Server 產生 token 紀錄 user 已登錄系統，然後把 token 還給 Client，在 Client 再次發送請求的時候，把 token 一起發給 Server，這樣 Server 就知道這一個 Client 是已經處於登錄的狀態。

意即所有的資源都可以 URI 定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化，資源相互的依賴性降低。

舉一個白話一點的例子：查詢員工工資：
第一步：登錄系統。
第二步：進入查詢工資的頁面。
第三步：搜索該員工。
第四步：點擊姓名查看工資。

這樣的操作流程就是有狀態的，查詢工資的每一個步驟都依賴於前一個步驟，只要前置操作不成功，後續操作就無法執行。如果輸入一個URL就可以直接得到指定員工的工資，這種情況就是無狀態的，因為獲取工資不依賴於其他資源或狀態，這種情況下，員工工資是一個資源，由一個 URL 與之對應可以通過 HTTP 中的 GET 方法得到資源，這就是典型的 RESTful 風格。

3. 可更高效利用快取來提高回應速度 (Cachable)

在 server-side，GET 過的資源，如果沒有被變更過，可以利用 cache 機制減少 request。
在 client-side，透過 client 端 cache 紀錄 cache 版本，若向 server 要求資源時發現 server 最新版與 cache 相同，則 client 端直接取用本地資源即可，不需要再做一次查詢

4. 分層系統架構 (Layered System)

5. 客戶端服務器分離 (Client-Server)

6. 充份利用 HTTP protocal(GET/POST/PUT/DELETE) (Manipulation of resources through representations)

7. 可執行程式碼的設計，像是 JavaScript（非必要實作項目） Code-On-Demand (optional)

參考文章：
https://zh.wikipedia.org/wiki/%E8%A1%A8%E7%8E%B0%E5%B1%82%E7%8A%B6%E6%80%81%E8%BD%AC%E6%8D%A2
https://tw.alphacamp.co/blog/2016-10-25-coding-basics-for-marketers-1
https://ithelp.ithome.com.tw/articles/10157431
https://www.itread01.com/content/1544242329.html
https://progressbar.tw/posts/53
https://blog.csdn.net/hjc1984117/article/details/77334616
https://www.zhihu.com/question/28557115
https://blog.csdn.net/hjc1984117/article/details/77334616
http://www.ruanyifeng.com/blog/2011/09/restful.html
https://blog.toright.com/posts/5523/restful-api-%E8%A8%AD%E8%A8%88%E6%BA%96%E5%89%87%E8%88%87%E5%AF%A6%E5%8B%99%E7%B6%93%E9%A9%97.html
https://blog.csdn.net/Jmilk/article/details/50461577
https://blog.csdn.net/matthew_zhang/article/details/63410421

資料來源：https://medium.com/itsems-frontend/api-%E6%98%AF%E4%BB%80%E9%BA%BC-restful-api-%E5%8F%88%E6%98%AF%E4%BB%80%E9%BA%BC-a001a85ab638