引言：介面決定軟體命運
軟體的未來在很大程度上取決於介面的演進。此處的「介面」雙關：
- 程式介面 (API)：軟體模組間互動的契約，以原始碼形式呈現。
- 使用者介面 (UI)：人與軟體的交互邊界。
歷史證明：所有在應用層面成功的軟體，無一不是先在 API 設計上滿足了開發者需求，即使終端用戶從未直接呼叫那些 API。
歷程回顧：關鍵里程碑
1. CP/M (1970s) — 商業軟體 API 的濫觴
- Gary Kildall 設計約 20 個系統呼叫，構成首個實用微機 API。
- 目標受眾：科學家/學者，非商業開發者 → 商業價值未被發掘。
2. MS-DOS — 比爾·蓋茨的商業化洞察
- 全盤複製 CP/M API 並擴充，鎖定「應用程式開發者」而非科學家。
- 建立「API 即平台霸權」模式：控制 API 者控制生態系。
3. Windows API — 醜陋但勝利的實用主義
- 代碼醜陋、結構混亂，但提供偽多執行緒、高效記憶體管理、易用 GUI。
- 程式員為了用戶量被迫投入，Windows API 成為事實標準，微軟花 5 年完成桌面壟斷。
- 教訓：API 好不好用次要，能不能解決開發者當下最痛的問題才是關鍵。
4. VBX / COM — 元件經濟的誕生
- Alan Cooper 的 Ruby → Visual Basic → VBX 介面 (COM 前身)。
- 動態擴展 IDE 功能，證明「介面即商品」：第三方可買賣元件，微軟收稅。
5. TCP/IP & Web — 打破機器邊界的通用介面
- Unix 世界貢獻 TCP/IP，讓異構機器自由通訊。
- Mosaic/Netscape 將「瀏覽本機檔案」延伸為「瀏覽全球資源」，TCP/IP 成為隱形基礎設施。
- 用戶從未直接呼叫 TCP/IP API，但整個資訊時代建立在其之上。
核心洞見：API 設計的三大鐵律
- 明確受眾：為「解決方案服務商」而非「電腦科學家」設計。Jini 重蹈 CP/M 覆轍，Sun 同樣瞄準學術圈而非 ISV。
- 成熟 API 預示軟體前景：手機/PDA 紅外通訊若無公共 API，永無互通可能；未來「陌生人服務」API 將讓裝置自動與周圍設施協商交易。
- 組合大於建構：現代 Web 開發不再鑽研底層技術創新，而是組合現成元件——對元件 API 的依賴程度空前提高。
未來想像：陌生人服務
當你走在街上，手持裝置自動與商店、售貨機、導航系統、路人裝置協商：
- 「這家店有我要的鞋子嗎？」→ 庫存 API 回應。
- 「附近哪個停車位空著？」→ 城市感測器 API 回應。
- 「幫我訂杯咖啡，我 5 分鐘到。」→ 支付/訂單 API 串聯。
這需要 跨廠商、跨平台、語義互通的通用 API 標準——比 TCP/IP 更高層、比 REST 更語義化的協議。
給 API 設計者的行動清單
- 先問「為誰設計」：內部模組？合作夥伴？公開生態？受眾不同，介面風格截然不同。
- 優先解決 80% 場景：不要為 20% 邊緣案例犧牲主流易用性（參見《學習 C++：實踐者的方法》二八法則）。
- 版本演進策略：語意化版本、向後相容、棄用週期公開透明。
- 文件即介面：OpenAPI/Swagger、範例代碼、錯誤碼對照表——文件不全等於 API 不存在。
- 安全內建：OAuth 2.0、Rate Limiting、審計日誌，而非事後補丁。
總結
從 CP/M 的 20 個系統呼叫，到 Windows API 的龐大族群，再到 TCP/IP 連接世界，VBX/COM 啟動元件經濟，歷次技術浪潮的贏家都是率先提供「足夠好、易上手、解決真問題」介面的平台。下一波浪潮——陌生人服務——同樣屬於那些能定義出「裝置間自動協商標準介面」的團隊。記住：介面不是技術細節，而是商業契約與生態邊界。
