目前 Server 只是把收到的 JSON 在 Console 上印出來，使用者端還沒有辦法收到任何之前串接 Gemini API 的回覆。所以接下來繼續處理昨天收到的 Webhook Event，先從 LINE 傳來的 JSON 中取得真正需要的text，再嘗試讓 Java 回覆訊息。

replyToken 跟 Channel Access Token的差別

replyToken 是用來回覆這次 Event 的 Token ，雖然跟前面提到的 Channel Access Token 都有 Token ，但兩者的用途其實不同一樣。 Channel Access Token 是從 LINE Developers 設定取得，並放在 HTTP 的 Authorization Header ，而 replyToken 則是從 Webhook Event 中取得，在回復訊息裡的 JSON Body 裡。
簡單來說，Channel Access Token 是告訴 LINE 「這個 Backend 有權呼叫 API」，而 replyToken 則是告訴 LINE 「我要回覆這一次 Event」。

從 JSON 找到需要的資料

由於 LINE 的 JSON 結構有好幾層，所以不能直接用.get()來取得文字，而是需要一層一層找到 events、message，最後才能取得需要的 text。這其實跟前面從 Gemini Response 中的概念是一樣的。

Reply Message API

回到今天的重點，就是把上述的 replyToken 和想要回覆的文字整理成 JSON，再透過 HTTP POST 傳送給 LINE。 Reply Message API 一樣是透過 HTTP Request 傳送資料，所以除了 URL 和 JSON Body 外，也需要設定 Request Header。這和前面串接 Gemini API 的流程也非常相似，只是 API Endpoint、驗證方式以及 JSON 格式不同。也就是 Request 的基本架構沒有改變，但「傳送的目的地」、「認證」以及「接收時要求的格式」都會有所不同。

實作

先從 Webhook Event 中取得使用者輸入的 text 和這次事件的 replyToken。

再透過 Reply Message API 傳送回 LINE。

最後成功讓 Java Backend 收到使用者訊息並將訊息回覆到 LINE。