API是什麼？
在初學RPA工具像Power automate或Ui Path很多人會先選擇使用錄製巨集的方式來做到資料的取得，錄製巨集的好處是它直接模擬使用者的操作來建立流程，這樣的方式快速好懂，但也有其限制，最直接的限制就是網頁的介面會一直迭代換新，只要稍微一改動，整個流程都需要調整一次。
這時候我們就可以了解另一個取得資料的方法，使用API取得資料。
如果要簡單說API是什麼？我會說API是一種「不用打開畫面，也能跟系統拿資料」的方式。
簡單的比較兩者流程：
- UI操作： 開網頁 -> 點按鈕 -> 輸入 -> 等畫面 -> 抓資料 -> 繼續流程
- API操作：發送請求 -> 等回應 -> 取得結果 -> 繼續流程
使用API會遇到的三個概念
API是像URL的東西: https://shop.com/api/users，當你輸入這個網址並送出就是對這個平台送出請求。
在API中的三個常見的核心知識：請求、回應、錯誤訊息
- Request（請求）：你要送什麼給系統。其中請求又有分成幾種類型
- GET（讀取）： 我想查資料（例如：查詢匯率）。
- POST（新增）： 我要建立新資料（例如：送出一張訂單）。
- PUT / PATCH（修改）： 我要更新現有資料（例如：修改會員地址）。
- DELETE（刪除）： 我要刪除資料（例如：刪除舊檔案）。
- Response（回應）：系統回你什麼。
- Status Code（狀態碼）：由三碼數字組成，其中常遇到的是2xx / 4xx / 5xx：
-200系列：成功。
-400系列：客戶端錯誤。
-500系列：伺服器錯誤。
- Body（回傳資料）： 也就是我們要的內容，通常是 JSON 格式。如果成功會返回我們要的資料、失敗的話會回傳錯誤訊息。
- 錯誤訊息：如果失敗，系統會告訴你原因（例如：權限不足、找不到資料），這對於除錯非常重要。
什麼是JSON格式？
RPA 開發者通常習慣看 Excel 或表格，看到 JSON (大括號 { }) 會卻步，但其實JSON 只是把資料「結構化」的一種方式。
但在網頁開發中，前後端之間要傳送資料常常是使用JSON格式當作資料的傳輸，這邊的使用情境是，小明填寫完自己資料的表單 -> 點選送出，
此時，前端資料實際上傳給系統前會先組合成JSON格式，也就是以下的樣子：
{
"name":"小明",
"age":22,
"hobby":["dancing", "singing", "sleeping"]
}
看到這個資料，會發現JSON其實不難理解，我想你應該可以猜到小明在表單上填寫了什麼資料，沒錯，他填寫了自己的名字、年齡及興趣愛好要傳送給系統。
而JSON的規律就是用{"Key": "Value"}來傳遞資料，
- Key (鍵)： 定義欄位名稱（如
name）。 - Value (值)： 實際的資料（如
小明）。Value 可以是文字、數字，甚至是清單（Array/List）。只要是先前介紹到的變數類型都可以當value來存放。
在 RPA 中，我們只需要學會「如何從 JSON 中抓出我們要的 Key」，就能拿到對應的 Value。
使用API取得資料前的認證方式
通常我們要使用平台的API，都要按照該平台規定的方式來串接平台的API來取得資料，這時候就會有驗證的問題發生。每個平台都需要先驗證過你發送過來的請求，驗證確認沒問題，才會安全把資料提供給使用者。
因為驗證的方式有很多種，這邊不會一一講解各個方式怎麼使用，而是讓大家有一個這樣的概念，之後在實際操作串接時遇到再個別按照他們的API使用手冊來操作。
RPA使用API的情境：
以上的介紹希望你有更了解API是什麼，而在RPA中又有哪些例子可能需要使用到API呢？
- RPA流程可以加入現在LLM（ChatGPT, Gemini）幫助使用者做判斷，如有這方面的需求就可以串接大型語言模型的API，並把它加入RPA流程中。
- 若公司CRM/ERP有開放API，可以直接透過 API 查詢或更新客戶資料。不管網頁介面怎麼改版（例如按鈕從左邊移到右邊）。
API的限制
以上介紹了API的特性跟使用，但它也有自己的缺點。API取得資料的方式並不是每個想取得的資料都有提供API，如果開發者沒有提供API的管道給使用者去使用那就沒辦法用API取得資料。現代平台若你想使用它們的API很多甚至要收費才提供API的管道。
測試神器：Postman
在串接API到RPA流程或寫入程式前，很多軟體工程師會使用Postman這個工具來做請求＋資料回應的測試，確保這個API可以正確取得到資料後再將設定複製到 RPA 軟體中，可以更有效率，這能幫你省下大量的除錯時間！
總結
雖然 API 的學習曲線比錄製巨集稍微陡峭一些，你需要習慣看 JSON、理解狀態碼、可能要學使用 Postman，但這是 RPA 程式思維的重要觀念。
當然，這不代表我們要完全拋棄 UI 操作。最完美的 RPA 架構，往往是「混合模式」：用 API 處理核心的資料交換，用 UI 處理老舊、沒有接口的軟體，選擇適合的方式來解決問題，在RPA自動化研究社先前的文章中也有探討什麼情境可以使用什麼工具合適。
寫完這篇文章後，我發現或許還會有很多疑問，像是不知道實際怎麼串接API？成功後怎麼取得要用的資料？這些部分我想，會需要另一篇文章解說，RPA實際串接API的操作，我將會新增相關的文章做更詳細說明！
雖然還沒有實際操作，但希望這篇文章能帶給你一些API的觀念，因為這個觀念是共通的不限於使用RPA工具，而是其他程式語言都是依照這樣的邏輯來取得資料。
延伸思考
讀完這篇文章，可以想想自動化流程：
- 盤點痛點： 你目前有哪些流程是因為「網頁載入太慢」或「介面改版」而經常報錯的？這些系統是否有提供 API？
- 動手嘗試： 可以試著申請一個免費的 API（例如天氣預報或匯率查詢），用 Postman 玩玩看！
