建議做法：使用 FIDL 類型和通訊協定定義任兩項可能會單獨更新的介面。在適用情況下，請採用 Fuchsia API 演進指南和 FIDL 評分量表。
- FIDL 具有版本管理註解。
- FIDL 提供 API 和 ABI 相容性保證。
- FIDL 支援變更類型定義、隨時間新增及移除方法，以及重新命名類型，實現軟轉轉換。
不建議使用：避免使用 FIDL 以外的語言來定義獨立更新相關的介面。其中包括純文字、JSON 和通訊協定緩衝區。
查看替代方案時，請想想看替代方案會具備哪些可更新性。
- 資料是否有結構定義？
- 結構定義能否隨時間變更，同時提供回溯/前向相容性？操作方式：
- 對結構定義進行哪些變更是 API/ABI 保留/破壞？在提交破壞性變更之前，您會如何知道？
- 電線格式穩定嗎？
建議：在設計用於平台外部使用的平台 API 和 ABI 時，請務必謹慎。設計時須確保可更新性，並找到方法來強制執行用戶端使用目標介面，而且不會提供規避介面的方式。
不建議採用：請避免將用戶端公開給不綁約的實作詳細資料。常見錯誤包括公開範圍較廣的功能或命名空間，以及透過元件 ID (例如 fuchsia-pkg:// 網址) 和診斷選取器外洩實作詳細資料。