同事問過一個問題：給前端呼叫的API，要把畫面需要的資料全部包在一支裡，還是拆成多支？如果是編輯頁面，其中一支讀取失敗，還要讓使用者繼續編輯嗎？

這兩個問題其實連在一起。要決定怎麼拆API，得先知道畫面上的操作依賴哪些資料；某份資料沒取得時，哪些事情還能做。今天要確認的，就是資料依賴與操作前提。

沒取得的資料，會影響哪個操作？

以待出貨單的編輯頁為例。畫面需要目前的收件資訊、可選擇的配送方式，旁邊另外顯示異動紀錄。假設規格允許交付物流前修改收件資訊，儲存時仍由後端確認目前是否可修改。

如果出貨單本身讀取失敗，連原本的收件人與地址都不知道，就不應把空白表單當成可編輯的既有資料。這時要明確顯示讀取失敗，讓使用者重試。

如果失敗的是異動紀錄，而它只是供查閱的輔助資訊，就可以在該區塊顯示錯誤，不一定要擋住其他編輯。反過來，如果規格要求先確認某筆異動才能執行操作，它就成了必要資料。能不能繼續，取決於用途，不能只看它放在畫面的哪個位置。

配送方式則要再細分。主資料已經帶回原本的配送方式，但選項清單沒取得，可以顯示原值並停用該欄位。不過，若配送方式依收件地址決定，這時也不能任意開放修改地址，否則原本保留的配送方式可能已經不適用。

能繼續編輯，不代表能直接儲存

假設規格允許單獨修改收件電話，而且這項修改不影響配送方式，那選項讀取失敗時，仍可能讓使用者修改電話。

但要先看儲存API的約定。如果它支援只更新指定欄位，可以只送出電話；如果它把整份表單視為完整資料，就要確認其他必要值已正確取得，不能把未載入的欄位用空值補上送出。

「沒有這份資料」「原本就是空值」與「這次讀取失敗」是不同情況。若前端全部用空白表示，使用者只是改電話，送出時卻可能順便清掉別的欄位。

因此，判斷是否能儲存，要連著看畫面的資料狀態、欄位之間的依賴，以及後端接受的修改範圍。按鈕可以點，不代表操作前提就成立；後端也仍須驗證這次修改符合規則。

一支或多支API，是根據這些依賴做選擇

如果幾份資料缺一不可，而且總是一起使用，整合成一支供這個頁面使用的API，可以減少前端組裝與協調的工作。代價是其中一部分變慢或失敗時，要決定整體等待、整體失敗，還是明確回傳各部分的結果。

如果各區塊能獨立使用，拆成多支就能分別載入與重試。例如異動紀錄暫時失敗，不必重新載入使用者正在編輯的收件資訊。但前端要管理每份資料的載入狀態，並依操作需要決定哪些欄位可以使用。

也可以把主要資料與必要選項一起取得，輔助紀錄另外讀取。不需要為了統一形式，讓所有資料都採相同做法。

另外，一支API不自動保證裡面的資料來自同一個時間點，多支API也不代表必然不一致。若操作需要一致的資料版本，就必須另外確認後端的讀取與更新約定，不能用API數量當成保證。

跟AI討論時，把可操作條件一起交代

可以讓AI根據畫面規格、讀取與儲存API，整理每個操作需要哪些資料，提出整合或拆分的方案。討論重點是某份資料失敗後，使用者還能完成哪些工作，以及系統如何避免送出不完整的內容。

API怎麼拆，要回到操作需要什麼資料。理解這些依賴，才能與AI一起判斷哪些失敗可以局部處理，哪些必須阻止使用者繼續。

中秋節前，公司做了個月餅領取頁面！
同事打開一看是個零：「今年沒有月餅？」
「有啊，只是庫存資料還沒載入。」
「那為什麼顯示已領完？」
程式查詢失敗，畫面數量顯示預設的 0 ...