###### tags: `持續 API 管理`
# 第 4 章：API 產品的十大支柱 part1

## 十大支柱
### 策略、設計、文件、開發、測試、部署、資安、監測、發現、變動管理

+ 如果你不投資任何支柱，產品註定會失敗。
+ 但你可以不用把心力投注在所有支柱，你可以視情況決定比重，並隨著時間與發展狀況進行調整
+ 每個支柱都包含一個與 API 有關的決定，支柱彼此之間範疇可能也會重疊

### 策略
+ 與組織的策略或商業模式有關
+ 為什麼要建構 API (目標)： 用 API 來支援企業
+ 直接營利：如 Line Bot API, 綠界 Payment API
+ 公司內部業務需要 API 支援
+ 考慮開放內部 API 給外界使用
+ 付費是否會造成使用障礙
+ 免費使用有時可以促進其他核心業務業績增長
+ API 如何協助你達成目標 (戰術)
+ 確認哪些支柱是成功的關鍵
+ 知道哪些用戶群可推動成功
+ 收集背景資料來推動決策工作
+ 範例：
+ 在你的平台增加與業務相符的功能：讓商業關係人參與早期設計階段，確保介面正確
+ 將內部資產貨幣化：找到用戶社群推廣，鎖定 API 受眾，並注重開發者體驗 (DX)
+ 收集商業想法：收集外部想法，向外界推銷 API，找到正確的支柱進行投資以提升使用率

+ 調整策略
+ 要隨時因應產品結果調整策略，如 API 進入大量使用階段
+ 要制定 OKR 或 KPI 衡量是否調整策略
+ 有外部因素影響時也要調整戰略，如政府政策、新對手等

+ 總結
+ API 的目標與戰術計畫
+ 衡量決策的影響力
+ 知道何時改變策略

### 設計
+ 在設計 API 的介面所做出的決定。當用戶使用你的產品時，介面是他們唯一會看到的東西。設計介面時，必須考慮的事項
+ 詞彙：用字與術語，是否有具 domain 意義的特殊詞彙
+ 樣式：Restful API, GraphQL, gRPC 等
+ 互動：API 如何滿足用戶需求
+ 安全性：哪些設計特點可以避免用戶犯錯或通知錯誤訊息
+ 一致性：設計風格是否與組織甚至是業界一致
+ DX 開發者體驗
+ 使用設計方法
+ 輕量級：自行迭代，收集資訊少，也可能意外獲得高回報
+ 謹慎型：收集到較多資訊，較花時間
+ 競品比較

+ API 說明格式
+ SOAP API: WSDL
+ CRUD: Open API
+ gRPC: Protocal Buffer

+ 『設計』的關鍵決策
+ 設計限制：團隊發表『樣式指南』，可能包含官方允許的詞彙、樣式與互動方式
+ 分享介面模型：API 說明格式

### 文件
良好的 API 文件有助於減少使用者開發時間與發生 bug 的機率。
通常有以下兩種基本做法，建議是兩者皆使用。

+ 教而不說：清楚記載 schema、錯誤代碼、request/response 高度根據事實呈現。
+ 說而不教：為用戶量身定做教學文件，給客戶於有限步驟完成 API 串接的 workshop

實務上，投資「文件」不宜過量，如果隨時讓文件與介面處於同步的狀態下，所耗費成本可能過高。而文件錯的時候也容易引起使用者不滿。

+ 『文件』的關鍵決策
+ 學習體驗是如何設計：一致性 vs 多樣性和創新量
+ 何時該撰寫文件

### 開發
+ 使用艱難的技術或沒人懂的語言：程式難以維護
+ 使用難用的工具或程式語言：程式難以變動
+ 使用框架與工具：API Gateway
+ 優點：集中管理，幫你做一些事情，降低開發成本
+ 缺點：修改的靈活性可能被限制在框架
+ 介面與實作關係
+ 讓實作符合你公布的介面設計是重要的品質指標
+ 當你改變介面，就必須重新實作
+ ==完成介面設計前，不能開發 API==
+ 可以考慮加入測試確認 API 是否遵守介面
+ 『開發』的關鍵決策

### 測試
+ 測試種類
+ 易用性與 UX 測試
+ 單元測試
+ 整合測試
+ 效能與負載測試
+ 安全測試
+ 產品測試
+ ...others

+ 測試驅動開發：成功執行這項策略可獲得高品質 API，因為隱含高度的可測試性。
+ Mock
+ 用戶端：模擬來自 API 用戶
+ 後端：模擬內部 API、第三方
+ 環境：模擬正式環境
+ API：沙盒環境
+ 『測試』的關鍵決策
+ 在哪裡測試
+ 多少測試才夠

### 部署
將 API 實作轉移到目標用戶可使用的環境
+ 處理不確定性：消除不確定性，同時接受不確定性
+ 人為錯誤
+ 硬體錯誤
+ 第三方錯誤
+ 過載
+ 不變性原則：增加不可改變的地方提升穩定性，如環境變數
+ 部署自動化
+ 『部署』的關鍵決策
+ 誰可以決定何時部署
+ 如何包裝部署