Web API設計原則(通過API和微服務實現價值交付)

作者：(美)詹姆斯·希金博特姆|責編:吳晉瑜|譯者:閆曉迪
出版社：人民郵電
ISBN：9787115605764

出版日期：2023/11/01
裝幀：平裝
頁數：280

人民幣：RMB 99.8 元售價：元

內容大鋼

本書從「由外而內」的角度引入API設計的概念，強調反映客戶和產品團隊的需求，將需求映射到特定的、架構組織良好的API，為編寫這些API選擇正確的樣式，並從零開始實現了一個真實的例子。本書旨在為設計新API或欲擴展現有API的人提供指導，幫助他們了解如何通過正確的設計過程來交付優秀的API，如何與設計團隊、客戶和其他利益相關者就具體的結果對齊思路，如何定義候選API，以及如何使API程序實現設計和管理過程的可擴展性。
本書適合所有參與規劃或構建API的讀者閱讀，包括但不限於架構師、開發人員、團隊領導者，以及相關技術人員或業務人員。

作者介紹

(美)詹姆斯·希金博特姆|責編:吳晉瑜|譯者:閆曉迪
詹姆斯·希金博特姆（James Higginbotham）是一名軟體開發者和架構師，在開發、部署應用程序和API設計方面擁有超過25年的經驗。他擅長與銀行、商業保險、酒店、旅遊、航空等行業的團隊和企業合作，能幫助團隊將業務、產品和技術策略統一到更易組合和模塊化的企業平台，指導企業完成數字化轉型之旅。詹姆斯曾多次舉辦研討會，熱衷向跨職能團隊推薦他提出的ADDR流程——通過基於產品的思維來確保業務和技術之間的一致性，以提供出色的客戶體驗。

第一部分  Web API設計簡介
  第1章  API設計原則
    1.1  Web API設計要素
      1.1.1  業務功能
      1.1.2  產品思維
      1.1.3  開發者體驗
    1.2  API設計即溝通
    1.3  審查軟體設計的原則
      1.3.1  模塊化
      1.3.2  封裝
      1.3.3  高內聚和松耦合
    1.4  基於資源的API設計
    1.5  資源不是對象或領域模型
    1.6  基於資源的API交換消息
    1.7  Web API設計原則
    1.8  小結
  第2章  協作式API設計
    2.1  為什麼需要API設計流程？
    2.2  API設計流程反模式
      2.2.1  泄露抽象反模式
      2.2.2  下一個版本設計修復反模式
      2.2.3  英雄設計工作反模式
      2.2.4  未使用的API反模式
    2.3  API設計優先的方法
    2.4  API設計優先並保持敏捷
      2.4.1  重新審視敏捷宣言
      2.4.2  API設計優先的敏捷性
    2.5  對齊-定義-設計-優化流程
    2.6  DDD在API設計中的作用
    2.7  API設計涉及每一個人
    2.8  有效應用ADDR流程
    2.9  小結
第二部分  對齊API的結果
  第3章  明確數字功能
    3.1  確保利益相關者思路對齊
    3.2  什麼是數字功能？
    3.3  專註于要完成的工作
    3.4  什麼是任務用例？
    3.5  任務用例的組成部分
    3.6  為API編寫任務用例
      3.6.1  方法1：當問題已知時
      3.6.2  方法2：當期望的結果已知時
      3.6.3  方法3：當數字功能已確定時
    3.7  克服任務用例的挑戰
      3.7.1  挑戰1：任務用例過於詳細
      3.7.2  挑戰2：任務用例以功能為中心
      3.7.3  挑戰3：任務用例需要額外的用戶上下文
    3.8  收集任務用例的技巧
    3.9  現實世界中的API設計項目
    3.10  任務用例示例

    3.11  小結
  第4章  收集操作和步驟
    4.1  將任務用例擴展為操作及其對應的步驟
      4.1.1  確定每個任務用例的操作
      4.1.2  將每個操作分解為若干步驟
      4.1.3  如果需求不明確，怎麼辦？
    4.2  通過事件風暴實現協作式理解
    4.3  事件風暴的工作方式
      4.3.1  步驟1：明確領域事件
      4.3.2  步驟2：創建事件描述
      4.3.3  步驟3：查看描述並確定差距
      4.3.4  步驟4：擴展領域理解力
      4.3.5  步驟5：查看最終描述
    4.4  事件風暴的好處
    4.5  主持事件風暴會議
      4.5.1  準備：收集必要的材料用品
      4.5.2  分享：溝通事件風暴會議
      4.5.3  主持：進行事件風暴會議
      4.5.4  總結：收集操作和步驟
      4.5.5  跟進：會後建議
      4.5.6  定製流程
    4.6  小結
第三部分  定義候選API
  第5章  明確API邊界
    5.1  避免API邊界反模式
      5.1.1  大型一體化API反模式
      5.1.2  過載API反模式
      5.1.3  輔助API反模式
    5.2  有界上下文、子域和API
    5.3  使用事件風暴探索API邊界
    5.4  通過操作找到API邊界
    5.5  為API命名並確定其範圍
    5.6  小結
  第6章  API建模
    6.1  什麼是API建模？
    6.2  API建模流程
      6.2.1  步驟1：收集API配置文件摘要
      6.2.2  步驟2：確定資源
      6.2.3  步驟3：定義API分類法
      6.2.4  步驟4：添加操作事件
      6.2.5  步驟5：擴展操作的詳細信息
    6.3  用序列圖驗證API模型
    6.4  評估API的優先順序和重用性
    6.5  小結
第四部分  設計API
  第7章  基於REST的API設計
    7.1  什麼是基於REST的API？
      7.1.1  REST是客戶-伺服器體系結構
      7.1.2  REST是以資源為中心的
      7.1.3  REST是基於消息的

      7.1.4  REST支持分層架構
      7.1.5  REST支持按需編碼
      7.1.6  超媒體控制
      7.1.7  什麼時候選擇REST
    7.2  REST API設計流程
      7.2.1  步驟1：設計資源URL路徑
      7.2.2  步驟2：將API操作映射到HTTP方法上
      7.2.3  步驟3：分配響應代碼
      7.2.4  步驟4：記錄REST API設計
      7.2.5  步驟5：分享並收集反饋
    7.3  選擇一種表徵格式
      7.3.1  資源序列化
      7.3.2  超媒體序列化
      7.3.3  超媒體消息傳遞
      7.3.4  語義超媒體消息傳遞
    7.4  常見的REST設計模式
      7.4.1  創建-讀取-更新-刪除
      7.4.2  擴展資源生命周期支持
      7.4.3  單例資源
      7.4.4  後台（隊列）作業
      7.4.5  REST中的長期運行事務支持
    7.5  小結
  第8章  RPC和基於查詢的API設計
    8.1  什麼是基於RPC的API？
      8.1.1  gRPC
      8.1.2  使用RPC時應該考慮的因素
    8.2  RPC API設計流程
      8.2.1  步驟1：確定RPC操作
      8.2.2  步驟2：細化RPC操作
      8.2.3  步驟3：記錄API設計
    8.3  什麼是基於查詢的API？
      8.3.1  了解OData
      8.3.2  探索GraphQL
    8.4  基於查詢的API設計流程
      8.4.1  步驟1：設計資源和圖結構
      8.4.2  步驟2：設計查詢和突變操作
      8.4.3  步驟3：記錄API設計
    8.5  小結
  第9章  用於事件和流的非同步API
    9.1  API輪詢的問題
    9.2  非同步API創造新的可能性
    9.3  回顧消息傳遞的基礎知識
      9.3.1  消息傳遞的樣式和位置
      9.3.2  消息的要素
      9.3.3  了解消息代理
      9.3.4  點對點消息分發（隊列）
      9.3.5  扇出消息分發（主題）
      9.3.6  消息流基礎知識
    9.4  非同步API樣式
      9.4.1  使用Webhooks的伺服器通知

      9.4.2  使用伺服器發送事件的伺服器推送
      9.4.3  通過WebSocket的雙向通知
      9.4.4  gRPC流
      9.4.5  選擇非同步API樣式
    9.5  設計非同步API
      9.5.1  命令消息
      9.5.2  事件通知
      9.5.3  事件承載的狀態轉移事件
      9.5.4  事件批處理
      9.5.5  事件排序
    9.6  記錄非同步API
    9.7  小結
第五部分  優化API設計
  第10章  從API到微服務
    10.1  什麼是微服務？
    10.2  微服務降低協調成本
    10.3  API產品和微服務之間的區別
    10.4  權衡微服務的複雜性
      10.4.1  自助服務基礎設施
      10.4.2  獨立的發布周期
      10.4.3  轉向單一團隊的所有權
      10.4.4  組織結構和文化影響
      10.4.5  數據所有權的轉移
      10.4.6  分散式數據管理和治理
      10.4.7  分散式系統的挑戰
      10.4.8  彈性、故障轉移和分散式事務
      10.4.9  重構和共享代碼帶來的挑戰
    10.5  同步和非同步的微服務
    10.6  微服務架構的樣式
      10.6.1  直接服務通信
      10.6.2  基於API的編排
      10.6.3  基於單元的架構
    10.7  合理調整微服務的規模
    10.8  API分解為微服務
      10.8.1  步驟1：明確候選微服務
      10.8.2  步驟2：將微服務添加到API序列圖中
      10.8.3  步驟3：使用微服務設計畫布，以收集設計細節
      10.8.4  其他微服務設計注意事項
    10.9  過渡到微服務時的注意事項
    10.10  小結
  第11章  改善開發者體驗
    11.1  創建一個API模擬實現
      11.1.1  API靜態模擬
      11.1.2  API原型模擬
      11.1.3  基於README的模擬
    11.2  提供輔助庫和SDK
      11.2.1  提供輔助庫的選項
      11.2.2  對輔助庫版本化
      11.2.3  輔助庫文檔和測試
    11.3  為API提供CLI

    11.4  小結
  第12章  API測試策略
    12.1  驗收測試
    12.2  自動化安全測試
    12.3  運維監控
    12.4  API契約測試
    12.5  選擇工具，以加快測試速度
    12.6  API測試的挑戰
    12.7  讓API測試不可或缺
    12.8  小結
  第13章  為API設計製作文檔
    13.1  API文檔的重要性
    13.2  API描述格式
      13.2.1  OpenAPI規範
      13.2.2  API Blueprint
      13.2.3  RAML
      13.2.4  JSON Schema
      13.2.5  使用ALPS的API配置文件
      13.2.6  使用APIs.json改進API發現功能
    13.3  使用代碼示例擴展文檔
      13.3.1  先寫好入門代碼示例
      13.3.2  使用工作流示例擴展文檔
      13.3.3  錯誤案例和生產就緒的示例
    13.4  從參考文檔到開發者門戶網站
      13.4.1  通過開發者門戶網站提高API採用率
      13.4.2  優秀的開發者門戶網站的要素
    13.5  有效的API文檔
      13.5.1  問題1：你的API如何解決我的問題？
      13.5.2  問題2：每個API操作都支持什麼功能？
      13.5.3  問題3：我如何開始使用API？
      13.5.4  技術文檔撰寫人在API文檔中的角色
    13.6  最小可行的門戶
      13.6.1  第1個階段：最小可行的門戶
      13.6.2  第2個階段：改進
      13.6.3  第3個階段：專註于增長
    13.7  用來製作開發者門戶網站的工具和框架
    13.8  小結
  第14章  為變更而設計
    14.1  變更對現有API的影響
      14.1.1  進行API設計差距分析
      14.1.2  確定什麼最適合API消費者
      14.1.3  變更策略
      14.1.4  變更管理是建立在信任之上的
    14.2  API版本控制策略
      14.2.1  常見的非破壞性變更
      14.2.2  不兼容的變更
      14.2.3  API版本和修訂版本
      14.2.4  API版本控制方法
      14.2.5  API版本的商業考慮因素
    14.3  棄用API

      14.3.1  制訂棄用策略
      14.3.2  宣布棄用
    14.4  創建一個API穩定性契約
    14.5  小結
  第15章  保護API
    15.1  危害API的潛在因素
    15.2  基本的API保護實踐
    15.3  API保護的組件
      15.3.1  API網關
      15.3.2  APIM層
      15.3.3  服務網格
      15.3.4  WAF
      15.3.5  內容分髮網絡
      15.3.6  智能API保護
    15.4  API網關拓撲結構
      15.4.1  APIM托管選項
      15.4.2  API網路流量注意事項
      15.4.3  拓撲結構1：API網關直連到API伺服器
      15.4.4  拓撲結構2：API網關路由到服務
      15.4.5  拓撲結構3：多個API網關實例
    15.5  身份和訪問管理
      15.5.1  密碼和API密鑰
      15.5.2  API令牌
      15.5.3  引用傳遞與值傳遞的API令牌
      15.5.4  OAuth 2.0和OpenID Connect
    15.6  構建內部API網關之前的注意事項
      15.6.1  原因1：API安全性是一個不斷變化的目標
      15.6.2  原因2：需要的時間比預期的更長
      15.6.3  原因3：預期的表現需要時間
      15.6.4  輔助庫怎麼樣？
    15.7  小結
  第16章  繼續API設計旅程
    16.1  建立API樣式指南
      16.1.1  鼓勵遵守樣式指南的方法
      16.1.2  選擇樣式指南的「基調」
      16.1.3  啟動API樣式指南的入門技巧
      16.1.4  支持多種API樣式
    16.2  進行API設計審查
      16.2.1  從文檔審查開始
      16.2.2  檢查標準和設計是否對齊
      16.2.3  審查測試覆蓋率
      16.2.4  添加試用支持
    16.3  鼓勵重用文化
    16.4  旅程才剛剛開始
附錄A  HTTP入門知識
    A.1  HTTP概述
    A.2  統一資源定位符
    A.3  HTTP請求
    A.4  HTTP響應
    A.5  常見HTTP方法

    A.6  HTTP響應代碼
    A.7  內容協商
    A.8  緩存控制
    A.9  條件性請求
    A.10  HTTP中的併發控制
    A.11  小結

同類熱銷排行榜

最近瀏覽的商品

Web API設計原則(通過API和微服務實現價值交付)