取消出貨的API回傳成功，客服畫面就可以顯示「已取消」嗎？要看這個成功，代表取消已完成，還是系統已經收到要求，準備稍後處理。這個差別會直接影響後面的程式。畫面要顯示什麼、批次能不能把這筆列入完成清單，都取決於呼叫端如何理解結果。今天要談的是介面契約，也就是雙方對輸入、結果與行為的共識。

成功的是收到要求，還是完成操作？

假設採同步處理，後端確認可以取消，完成資料寫入，並確保出貨流程不會再交付這張單據，才回傳取消成功。呼叫端拿到結果後，就可以顯示「已取消」。至於如何避免取消與出貨同時成功，是實作必須做到的保證，不能只靠回傳文字宣告。

另一種設計是先收下取消要求，交由背景程式處理。這時回傳的成功，只代表要求已受理。等到真正執行時，仍可能發現商品已經交付物流，最後無法取消。

兩種設計都可能合理，但呼叫端能做的判斷不同。前者能確認取消完成，後者只能顯示「取消處理中」，再透過約定的查詢方式取得結果。查詢用的識別也要能對應這次要求，避免拿到另一筆操作的結果。

所以不能只找到return success就結束。還要往前看：回傳之前，究竟已經完成哪些事情？

沒拿到成功，也不一定能判定失敗

相反方向也要想清楚。後端明確回覆「已交付物流，不能取消」，代表這次要求被拒絕。呼叫端可以顯示原因，批次也能把它列入未取消的清單。

但如果等待回應時逾時，就只知道這次沒有取得結果。取消可能尚未執行，也可能已經完成，只是回應沒有送達。因此，不能只因為逾時，就認定操作失敗並重新執行。能不能安全重送，要看這個操作是否具備防止重複處理的設計，Day14再繼續談。

所以「已受理」「已完成」「明確拒絕」與「結果尚未確認」，會支持不同的後續動作。若全部壓成一個成功或失敗，呼叫端就可能失去判斷所需的資訊。

不必為每支介面設計一大套狀態，但只要差異會改變後續處理，就應該有辦法辨識。結果未確認時，需要依約定查詢或處理，不能直接當成取消失敗，更不能只看到失敗就一律重送。

回傳格式一樣，承諾也一樣嗎？

假設為了縮短等待時間，團隊打算把原本同步完成的取消功能改成背景處理。即使回傳欄位與型別完全沒變，只要成功的意思從「已取消」變成「已受理」，舊呼叫端的判斷就不再成立。

與AI討論這類修改時，除了提供新的處理流程，也要交代哪些呼叫端仍依賴原本的完成條件。接著一起追查畫面提示、批次統計與後續動作，決定如何讓呼叫端辨識受理與完成。

驗證也要跨過回傳的那一行。例如讓背景工作暫停在尚未執行的階段，確認畫面仍顯示處理中，批次不會把它算成完成；等取消結果確定後，再檢查兩邊是否正確更新。這樣測到的，才是呼叫雙方對結果的理解是否一致。

回傳結果要有明確、具體的意思，而且符合實際完成的事情，讓呼叫端知道下一步可以做什麼。

同事做了個Log查詢頁面給我看。
我一按查詢，直接跳出Error。
同事淡定地喝著咖啡：「只是這個條件查不到Log。」
「那顯示查無資料就好了吧，為什麼要回ERROR？」
「因為查不到資料啊。」

我的CPU當場燒毀