API 的全名是 Application Programming Interface，是定義應用程式之間如何「互動」的規範。
API 可以讓不同的程式語言或應用程式之間進行溝通或交換資料，透過可以互相呼叫對方的功能（這個動作工程師們常會說「打 API」），進而達到資料交換、功能擴充等目的。
API 就像是一家餐廳的服務生。你去餐廳點餐時，不需要知道廚房裡的運作方式，只要按照菜單上的選項跟服務生點餐，廚房就會根據你的需求做出食物，然後送到你的桌上。
你（客人）→ 服務生 → 廚房 → 服務生 → 上菜 🥗
瀏覽器 → API → 後端應用程式 → API → 在瀏覽器上呈現資料
不過實際上的應用，更多時候是會傳一些資料給 API，請它代為查詢或處理，所以會更像這樣：
你（客人）→ 把 🐓 + 🐖 交給服務生 → 廚房 → 服務生 → 上菜 🍗 + 🍖
範例：
承上，在使用 API 可能會也可能不會傳送額外的資料，先不論傳送的是什麼資料，以目前 HTTP 傳送資料的方式來說有好多種不同的「動詞（Verb）」，常見的有以下幾種：
| HTTP 動詞 | 餐廳中的對應行為 | 作用 |
|---|---|---|
| GET | 「服務生，請給我菜單！」 | 查詢資料，不做修改 |
| POST | 「我要點一份牛排！」 | 新增一筆資料 |
| PUT | 「請把我的牛排換成雞排！」 | 更新整筆資料（全部修改） |
| PATCH | 「請幫我把牛排的熟度改成七分熟！」 | 更新部分資料（局部修改） |
| DELETE | 「我不吃了，幫我取消訂單！」 | 刪除資料 |
可以從頭到尾都只用 GET 嗎？想要一招打天下當然可以，只是每種 HTTP 動詞都有它設計出來的目的，而且有些 API 會限制只能用特定的動詞，所以要看實際的需求以及 API 的文件來決定要用哪一種動詞。
當我們對 API 發出「請求（Request）」的時候，也就是常會聽到工程師說的「打 API」，不管成功或失敗，API…不是，更精準的說應該是伺服器都會給個「回應（Reponse）」。
在這個回應裡除了會有我們預期看到的資料之外，還會有一個叫做「狀態碼（Status Code）」的東西。狀態碼是一個數字，代表這次請求的狀態，透過這個數字我們可以知道這次的請求是什麼情況，是成功、失敗還是其他的狀況。