---
# System prepended metadata

title: 第 4 章：API 產品的十大支柱 part1
tags: [持續 API 管理]

---

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