基本解釋

API（Application Programming Interface），中文翻為應用程式介面，用一句話來解釋的話，就是：兩個應用程式（電腦）接觸時所要依照的規範。

再用白話一點的方式來解釋，就是：「程式跟程式之間的面交規範。」

以面交買東西為例，假如今天我要跟某個店家面交買東西，那以下可能是他會事先定好的注意事項：

1. 你在哪個地方可以跟我碰面。
2. 你要給我什麼（例如錢、身分證件）。
3. 這樣我就會給你什麼。

假如我今天要預約要買鋼琴，那他會事先跟我說：

1. 你可以在臺中的某個街道跟我碰面。
2. 你要給我事先約好的鋼琴金額、身分證件。
3. 我會給你鋼琴。

現在把鋼琴換成是某個「電腦資料」，比如說 NBA 的球員數據好了。 如果我今天想要找 Nikola Jokic 去年整年的數據，那我可能就會去找有提供數據的店家，他也已經定好面交規範：

1. 你可以在某個秘密網址找到我。
2. 你要給我你想要哪一年的什麼數據。
3. 我就會給你球員的數據。

這個東西翻成程式的語言就是：

1. URL：你可以在某個秘密「網址」找到我。
2. Request：我需要你給我「要求」的東西。
3. Response：我會「回應」給你相關的資料。

API 的用法

以下我會舉例三種方法：GET, POST, PUT。

GET

字面意思，GET 指的就是「拿取」資料。

以在 Instagram 貼文為例。如果今天我要看某個人的某篇文章，於是我點進了這個文章頁面。這時 Instagram 的前端工程師就要跟後端去拿資料，通常就會用 GET。

他們之間所定的 API 規則可能長這樣：

URL: 127.0.0.1/articles
Request: article_id, user_id
Response: time, content, likes, comments

• 我們可以在 127.0.0.1/articles 這個網址碰面。
• 你要給我的東西是：
  • 你想要看哪篇貼文（article_id）
  • 想要看這篇貼文的是誰（user_id）（如果發文的人跟使用者不是好友，可能會被擋住。）
• 我會回傳給你：
  • 發文時間（time）
  • 文章內容（content）
  • 有誰按讚（likes）
  • 留言有哪些（comments）

POST

POST 可以想成是 PO 文，用學術一點的解釋就是，使用者在資料庫「創建」一筆新的資料。

以使用者要發一篇新的文為例，API 規格可能長這樣：

URL: 127.0.0.1/articles
Request: user_id, content
Response: article_id, "發文成功"

雖然這邊的網址跟 GET 一樣，但是因為一個是 GET，一個是 POST。用法不同，所以可以同時存在，不會衝突。

• 我們可以在 127.0.0.1/articles 這個網址碰面。
• 你要給我的東西：
  • 發文的人是誰（user_id）
  • 文章內容（content）
• 我會回傳給你：
  • 這篇文章的在資料庫是編號多少（article_id）。
  • 「發文成功」（message）。

PUT

可以 PUT 想成是 Edit（編輯）。

假設今天使用者要編輯貼文，API 規格可能長這樣：

URL: 127.0.0.1/articles
Request: article_id, content, user_id
Response: "發文成功"

• 我們可以在 127.0.0.1/articles 這個網址碰面。
• 你要給我的東西：
  • 這是哪篇文章（article_id）
  • 新的文章內容（content）
  • 發文的人是誰（user_id）、
• 我會回傳給你：「發文成功」（message）。

你可能有注意到這三個 API 的 URL 都一樣，這樣會不會打架？
不會，因為是程式會把 GET, POST, PUT 這些動作看成是不同的。

一些工作用語

在公司裡面，通常大家會用的詞語是「打」。我可以稍微舉例一些詞句：

• 我按下這個按鈕的時候需要拿到資料，這時候應該要「打」這一隻 API。
• 這一隻 API 漏了什麼參數，我需要你給我，可以修改一下嗎？

總結

以上是關於 API 的白話分享，希望這篇文章對你有幫助！

工作之前我也是花了好多的時間搞懂到底什麼是 API，不過其實工作之後會覺得，這根本不是一個「學問」，比較像是一個習以為常的用品。或許這也是為什麼，當有人問一個工程師說：「什麼是 API？」對方也會一時之間不知道怎麼回答。