上次我們已經聊過怎麼讓 API Gateway 跟 Lambda 搭上線，今天要升級一下，來聊聊怎麼讓這兩位上演一場「丟球接球」的默契秀 —— 也就是 API Gateway 把參數丟給 Lambda，然後 Lambda 接到球之後，乖乖幫你做程式邏輯處理。

老實說，一個 API 如果不能傳參數，那就跟咖啡店只賣空杯子一樣，外觀看起來很專業，實際上完全沒屁用。

HTTP 方法：RESTful 的武林門派

在開始之前，我們得先來溫習一下 HTTP 方法，也就是俗稱的「HTTP Actions」。這些方法就像武俠小說裡的門派，每一個都有自己的絕學：

• GET：就是伸手要東西，通常用來「讀取」資料。
• POST：丟資料給伺服器，通常用來新增或觸發什麼動作。
• PUT：整包更新，像是直接把一份新的履歷整本砸給 HR。
• DELETE：刪掉資源，工程師最愛用來清掉錯的資料再假裝沒事發生。
• PATCH：小修小補，像是線上改履歷 typo。
• HEAD：只要看標題，不看內文。超像點進八卦版只想看樓主有沒有附圖。
• OPTIONS：問伺服器「欸，你支援什麼？」這通常是瀏覽器幫你自動問的，不用自己去當客服。

其他冷門的我就不提了，因為你可能很難遇到。

GET vs POST：傳參數的愛恨情仇

身為 API 的門神，最常用的其實就 GET 跟 POST。這兩兄弟傳參數的方式不太一樣，各自有優缺點：

• GET：參數直接掛在 URL 上，像 https://example.com/api?name=foo&age=22。
  • 優點：直覺、方便，複製貼上就能 debug。
  • 缺點：全世界都看得到你在傳什麼，傳個帳號密碼就像在捷運車廂裡大喊「我愛你」。
  • 還有一個致命傷：URL 有長度限制（大概 2048 字），所以你要傳一份 20MB 的履歷？抱歉，先幫你剪掉 19.9MB。
• POST：參數塞在 request body 裡。
  • 優點：比較隱私，路人不會直接看到；容量大，檔案上傳也沒問題。
  • 缺點：debug 要麻煩一點，工程師會忍不住抱怨：「媽啊，這 payload 誰寫的？」

傳參數差異表

下面來一個表格，讓大家快速比較 GET 跟 POST 的差別：

實作時間：打造你的第一個 Lambda（GET 參數版）

前面我們講了一堆 GET 跟 POST 的愛恨情仇，這次我們要來點實作，畢竟工程師的信仰只有一個：能跑就好。

既然要測試 API Gateway 怎麼把參數傳進 Lambda，那我們第一步當然就是建立一個可以接收 query string 的 Lambda。

聽起來很帥？其實就是一個 Lambda function + 幾行程式碼，然後你就能用網址把參數丟進來，Lambda 幫你撿起來處理。就像早上訂早餐，你喊「小的要大冰奶、少冰、半糖」，店員（Lambda）會自動翻譯成：「好，一杯大冰奶、少冰、半糖」並寫進小白單。

Lambda 建立怎麼點？前幾篇文章已經講過了，沒看過的同學 → 請翻課本。
還記得怎麼建立的就直接做，不記得的… 先 Google「AWS Lambda 建立 function」吧(現在好像比較流行用AI )，因為大家都這樣。

先附上必要參數：

• Function name：lambda-api-get（名字隨便取，但取到好笑的會讓 PM 更快樂）
• Runtime：Python 3.13（畢竟工程師的 Python 版本永遠比你的 macOS 更新得快）
• Timeout：30 秒（照理說下面這個繁體應該不用這麼久 , 先設定一下,比較不會遇到意外 ）
• 程式碼如下：

import json

def lambda_handler(event, context):
    # 取得 URL Query String 中名稱為 name 的值
    name = event['queryStringParameters']['name']
    print(event)
    return {
        'statusCode': 200,
        'body': json.dumps(f'Hello!! {name}')
    }

這段 code 幹了什麼事？

1. 從 event 抓參數。
2. 把 event 的內容印出來，之後比較好 debug。
3. 回傳一個 JSON，假裝自己很友善。

小提醒：記得寫完之後要 Deploy，不然你會 debug 半小時，然後才發現原來你一直在呼叫舊版本。這種事工程師都幹過。

API Gateway 的設定

我們才剛生了一個會接 GET 參數的 Lambda，這次我們要讓它有個正式的「大門」──API Gateway。不然你 Lambda 寫得再香，沒大門就是在家裡自言自語，完全沒人聽到。

所以今天的重點就是：在 API Gateway 建立一個叫 lambda-api 的 Resource，然後幫它安裝兩個「技能樹」──GET 跟 POST。是的，你沒看錯，是兩個。

你可以把 Resource 想像成一個人，而 Method 就是這個人會的動作。
例如：

• GET = 問候語：「欸你午餐吃什麼？」
• POST = 點餐動作：「老闆我要雞排加辣」
• PUT = 更新點餐：「啊不對改成鹽酥雞」
• DELETE = 退餐：「算了我減肥，整個取消」

所以很合理，一個人（Resource）不會只會一個動作（Method）。要是你認識的人只能「GET」不會「POST」，那大概就是伸手牌同事，只會要東西不會給東西。

好，廢話講完，來點操作：

1. 建立 Resource
   • 進到 API Gateway 主畫面 → 左邊找 Resource → Create Resource。
     
   • Resource 名稱輸入：lambda-api。
     
     （至於畫面上的 CORS？先別問，這東西就像你人生裡的技術債，以後一定會遇到，但今天不是我們要處理的主題 XD）
   • 然後直接點 Create Resource，畫面跳出一個綠勾勾。
2. 建立 Method

• 在 lambda-api 上點「Create Method」。
  

1. Method Type 選 GET（先暖身一下）。
2. Integration Type → 選 Lambda function。
3. 重點來了！ Lambda Proxy Integration 要記得勾！
   • 沒勾的話，你的參數會像寄錯地址的包裹一樣直接消失，然後你 debug 半天以為自己在耍笨。
4. Region 要對，別一不小心選到 Tokyo，結果你的 Lambda 在美東，參數飛去繞地球一圈還收不到。
5. Lambda 名字 → 選我們剛剛建立的 lambda-api-get。
6. 參數：輸入 name。至於「是否必填」跟「要不要 cache」？隨你，反正到最後大家都會忘記自己有沒有勾。
7. 按下 Create Method → 成功！
   

建立成功之後，我們可以在左邊的Lambda清單當中看到 lambda-api 的下方多出了一個Get method， 最後千萬不要忘記點擊右上角的 Deploy API 來進行部署到 prod 環境 。

3. 部署到 Stage

• 這裡千萬不要忘記：要去右上角點 Deploy API。
• 選擇 prod 這個 Stage。
  
• 再點一次 Deploy。
• 忘了這一步會怎樣？就像你寫完程式沒 git push，結果同事問你功能在哪裡，你只能乾笑。

部署成功之後，就可以看到 Stage prod 的環境下面有多了一個 lambda-api ，然後 Method 是Get 的項目。當下 prod 環境的 URL 就寫在 Invoke URL 裡：

如果我們想要知道這個 Get 的 URL 是什麼？可以點選一下 Stage 項目當中的 lambda-api 的 Get 項目，然後注意中間的 Invoke URL： https://b5ou0dlsdc.execute-api.us-east-1.amazonaws.com/prod/lambda-api

測試結果：工程師的快樂源泉

經過千辛萬苦，我們終於搞定了 API Gateway + Lambda 的串接，現在該來看看它到底能不能動了。
畢竟在工程師的世界裡，能不能動比會不會寫還重要。

用瀏覽器測試：

因為我們的 Method 是 GET，所以最偷懶的測試方式就是──直接開 Chrome，貼上 URL + 參數，Enter 一按，結果就出來了。

部署成功後，畫面會跑出一個 Invoke URL，長這樣：https://b5ou0dlsdc.execute-api.us-east-1.amazonaws.com/prod/lambda-api

要測試 GET 的 URL？直接加參數：
https://b5ou0dlsdc.execute-api.us-east-1.amazonaws.com/prod/lambda-api?name=mich

參數 name=mich 被丟進去之後，Lambda 就很乖地回傳一段訊息給你。
瀏覽器上會看到「Hello!! Mich」，這一刻，你會覺得前面一切的辛苦都是值得的 。

用 curl 測試：命令列信仰

瀏覽器測試太 low？工程師真正的浪漫當然是打開 Terminal，用 curl。
畢竟跟同事說「我用 curl 打 API」比說「我用 Chrome 測」有面子多了。
指令如下：
curl https://b5ou0dlsdc.execute-api.us-east-1.amazonaws.com/prod/lambda-api?name=mich

如果一切順利，你會看到 Lambda 帥氣地回「Hello!! Mich」。

但是！如果你是在 Windows 下打 curl，恭喜你，很可能會跳出這一串讓人滿頭黑人問號的錯誤：

curl: (35) schannel: next InitializeSecurityContext failed: 
CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - 撤銷功能無法檢查憑證的撤銷

這應該是Windows下面HTTPS的 Library 在檢查評證的時候有發生問題造成的原結果。

解決方式也很工程師：直接無視。加上 --insecure，跳過憑證檢查：
改用
curl --insecure https://b5ou0dlsdc.execute-api.us-east-1.amazonaws.com/prod/lambda-api?name=mich

然後就會成功看到熟悉的 Hello!! Mich。
至於安全性？工程師心想：「先能跑再說啦。」

想不到只講 GET 的參數傳遞，就能寫這麼久。
難怪工程師常常覺得一個小功能可以拖到兩個 Sprint，因為要講清楚講明白真的很花時間啊！

所以今天我們先收工，畢竟連電腦都該休息了。
POST 的故事？那就下集待續吧，各位明天見。