API 串起來，不代表系統真的整合了

電商平台與物流商的系統串接，又碰到一個很熟悉的場景。

一開始的討論通常很順利：

• 「有 API 嗎？」有。
• 「訂單可以傳過去嗎？」可以。
• 「物流狀態可以回傳嗎？」沒問題。

聽起來好像工程師把 API 接起來就好了。但真的開始整合，才發現串接成功，往往只是問題的開始。

API 串起來，不代表系統真的整合了。

真正的問題都長在例外裡

一旦開始處理真實訂單，問題就一個一個冒出來：

• 訂單取消了，物流商已經接單怎麼辦？
• 分批出貨後，訂單狀態怎麼回寫？
• API Timeout，但對方其實已經處理成功，要不要重送？
• 訂單已經出貨，客戶又申請退貨怎麼辦？
• 兩邊資料不一致，到底以誰為準？

這些問題沒有一個是「API 能不能通」的問題。它們是業務規則、責任歸屬和狀態管理的問題。在會議上說「沒問題」的時候，大家想的通常是 Happy Path；但系統上線後每天要面對的，是各種不 Happy 的 Path。

更麻煩的，其實是測試

每個系統單獨測試都正常，不代表整條流程真的正常。

電商平台說：「我們 API 回傳成功了。」物流商說：「我們也有收到資料。」兩邊都沒說錯。但真正要驗證的是：

• 客戶下單後，訂單能不能正確進入物流系統？
• 出貨、取消、退貨，狀態能不能完整同步？
• 網路中斷、資料重送，會不會產生重複訂單？
• 中間有一個環節失敗，能不能恢復？
• 修好一個問題，會不會讓原本正常的流程又壞掉？

這些都不是單純測到 API 回傳 200 OK 就能解決的。

要有人站在整條流程的角度

這也是為什麼我現在特別在意 End-to-End Testing。

測試不能只由各系統廠商各自完成，而是要有人站在整個業務流程的角度，確認從客戶下單、到物流出貨、再到狀態回寫與異常處理，整個流程真的可以運作。

而且不能只測 Happy Path。真正容易出問題的，往往是取消、重送、超時、部分成功，以及人工介入後的資料同步。

我現在會用四個問題，檢查一個整合專案有沒有想清楚：

• Ownership：資料與異常處理，誰負責？
• State：跨系統的狀態，如何保持一致？
• Testing：誰負責完整流程與異常情境的驗收？
• Reconciliation：資料錯了，如何發現、修正與追蹤？

這四題如果有一題答不出來，通常代表這個整合還停在「接起來」的階段。

三個不一樣的完成

我最大的體會是：

Connectivity ≠ Integration ≠ Production Ready

• Connectivity 是兩邊能交換資料。
• Integration 是兩邊能一起把一件事做對，包括出錯的時候。
• Production Ready 是這件事每天、在真實流量下都能穩定運作，出了問題有人知道、有人處理、能追蹤。

接起來只是起點。真的整合，是不同系統、不同廠商、不同團隊能一起把一件事做完，而且有人對結果負責。

最後

整合不是讓系統互傳資料就好，還要整條流程驗得過、出錯救得回來、上線後跑得穩。

下次在會議上聽到「有 API，接起來就好」的時候，我大概會先笑一下，然後問：那取消的時候呢？