一句話：API 就是幫兩個程式互相「點餐」的服務生。你不用懂廚房怎麼運作，只要會看菜單、開口點餐，餐點就會送到你面前。
閱讀時間約 8 分鐘 · 完全不需要程式背景 · 內含可以動手玩的小模擬器
想像你走進一間餐廳，坐下來想吃一碗牛肉麵。
你不會自己衝進廚房、翻冰箱、開瓦斯爐——你只要跟服務生說「我要一碗牛肉麵，不要辣」。服務生把你的需求傳到廚房，廚房做好之後，服務生再把麵端回來給你。
下面這個小模擬器，你可以親手「點餐」一次，看看資料是怎麼跑的：
注意到了嗎？右邊那串看起來像亂碼的東西，是 API 回傳給程式看的「原始餐點」（格式叫 JSON）；App 收到後會把它變成左邊那種人類看得懂的漂亮畫面。API 服務的對象是程式，不是人——這是它跟一般網頁最大的差別。
API 是 Application Programming Interface 的縮寫，中文叫「應用程式介面」。聽起來很硬，拆開來其實很好懂：
合起來：「讓應用程式之間互相溝通的窗口」。餐廳的菜單就是一種介面——它規定了你能點什麼、怎麼點；API 也一樣，它規定了程式能要什麼資料、要怎麼開口。
API 不是工程師的專利，它藏在你每天的手機裡：
你的手機沒有氣象雷達。App 是透過「氣象局的 API」去要資料：「請給我台北今天的天氣」，氣象局的伺服器回傳數字，App 再畫成漂亮的太陽圖示給你看。
你在某個新網站按下這顆按鈕時，那個網站其實是透過 Google 的 API 去問：「這個人是誰？他同意登入嗎？」你不用重新註冊，密碼也不會交給對方。
購物網站自己不碰你的信用卡。它把付款需求透過 API 交給專業的金流公司處理，對方回覆「付款成功」，網站才顯示訂單成立。
外送平台沒有自己派車測繪全世界的路。它們呼叫 Google 地圖的 API，把「地圖 + 導航」這道菜直接端進自己的 App 裡。
程式跟 API 點餐時送出的東西叫 Request（請求），API 端回來的東西叫 Response（回應）。把它想成點餐單和出餐就好：
| 去哪間店 | weather.gov.tw→ 網址（要找哪個 API） |
| 點什麼 | 今天的天氣→ 要哪種資料 |
| 備註 | 地點＝台北→ 參數（細節條件） |
| 會員卡 | 卡號 ab12…→ API 金鑰（證明你有資格點） |
| 出餐狀態 | 200 成功上菜！→ 狀態碼（200＝成功） |
| 餐點內容 | 晴，31°C，降雨 10%→ 資料本體（JSON 格式） |
如果點了菜單上沒有的東西，服務生會回「404：查無此菜」——對，就是你看過的那個 404。
所以下次看到網頁出現「404 Not Found」，你可以優雅地說：喔，服務生說廚房沒有這道菜。
你點牛肉麵時，不需要知道湯頭熬了幾小時。同樣地，App 跟氣象局要天氣時，不需要知道對方的衛星和超級電腦怎麼運作。把複雜的事包起來，只留一個簡單的窗口——這叫「封裝」，是 API 最迷人的地方。
餐廳換了新爐子、新主廚，你的點餐方式完全不變。只要「菜單（API 規格）」不變，廚房內部怎麼升級都不影響客人。這讓不同公司、不同系統可以放心地互相合作。
客人不能隨便闖進廚房，是為了衛生與安全。API 也一樣：它只開放「該給的資料」，其他一概擋住。加上「會員卡」（API 金鑰）機制，還能控制誰可以點、一天最多點幾次。
API 不是你下載的軟體，它比較像一份「服務約定」——某家公司說：「你照這個格式問我，我就照這個格式回答你。」實際使用它的是工程師寫的程式，一般使用者是間接享受到它的好處。
就是「會員卡」。很多 API 需要先申請一組鑰匙，點餐時出示，對方才知道你是誰、有沒有付費、今天點了幾次。所以金鑰要保管好——就像你不會把會員卡隨便借人，不然帳單算在你頭上。
「串接 API」就是工程師把自己的程式跟別人的 API 接起來，讓兩邊可以通話。例如把公司網站「串」金流 API，網站就有刷卡功能了。串接的過程，本質上就是教程式怎麼看菜單、怎麼點餐、怎麼收餐。
現階段知道概念就夠：REST 是目前最流行的一種「點餐禮儀」（大家約定好的溝通規則）；JSON 是最常見的「餐點包裝格式」（就是模擬器右邊那種大括號文字）。你不需要會寫，只要聽到時知道它們在講什麼層面的事。