hiskio

    Web API設計原則

    API與微服務傳遞價值之道

    收集中
    US$16.40

    內容簡介


    《Web API設計原則》涵蓋了在設計API時的原則與流程，透過書中的準則，帶領讀者設計出高成效的API，作者首席顧問James Higginbotham具有豐富的實戰經驗，帶領您與團隊成員建立共識，並設計出高價值的API，並將此設計流程從小團隊擴展到全組織。

    作者從「從外向內」(outside-in)的視角檢視API設計，聆聽來自用戶與產品團隊的意見，彙整外部需求，並根據外部需求進行API設計，並確保API的架構條理分明，也談到如何選擇合適的API風格進行實作，書中透過一個實際的案例，為打算設計新API或擴展現有API的人員提供指導。

    ‧用正確的設計流程交付出色的API
    ‧為設計團隊、用戶及其他成員建立共同的目標
    ‧製作工作故事(job story)、進行事件風暴(EventStorming)與建構數位能力(digital capability)模型
    ‧正確的釐清需求，並歸納成格式一致的API Profile
    ‧從REST、gPRC、GraphQL、event-based async API(事件式的異步API)等數種API風格中挑選最佳實現方案
    ‧從文檔編寫人員、測試人員和客戶的反饋改進設計
    ‧將API解構成微服務
    ‧累積API經驗與策略，實現可擴展的設計與管理流程

    不論你是架構師、開發者、團隊領導人、團隊經理，或是任何提供「API-as-a-product」(API即產品)的技術或商業人士，凡是與API規劃或建構有關的人士，本書對您會是相當有價值的參考資料。

    作者介紹


    作者James Higginbotham是開發者，也是架構師與顧問，在開發、佈署應用程式、API等方面有超過25年的經驗，他的諮詢公司LaunchAny主要負責輔導企業數位轉型，經驗涵蓋銀行業、保險業、服務業、旅遊業以及航空業等，幫助企業將商業、產品、技術整合成模組化的架構，使企業成為可承載多元模組的戰略平台。

    目錄


    編輯序
    推薦序
    前言
    致謝
    關於作者

    Part I 初探 Web API設計
    第一章 API 設計原則
    第二章 API 設計與團隊合作

    Part II 尋求一致性
    第三章 鑑別數位能力
    第四章 產生活動與步驟

    Part III 定義 API
    第五章 界定 API 邊界
    第六章 建立 API 模型

    Part IV 設計 API
    第七章 REST API 設計
    第八章 RPC 與 Query-Based API 設計
    第九章 異步 API

    Part V 優化 API 設計
    第十章 從 API 到微服務
    第十一章 優化開發體驗
    第十二章 API 測試策略
    第十三章 撰寫 API 設計文件
    第十四章 API 的改版規劃
    第十五章 API 防護
    第十六章 繼續在 API 設計的航道上

    附錄 HTTP 入門

    章節目錄

    • 1-1
      封面
    • 1-2
      書名頁
    • 1-3
      目錄
    • 1-4
      編輯序
    • 1-5
      推薦序
    • 1-6
      前言
    • 1-7
      致謝
    • 1-8
      關於作者
    • 1-9
      Part I 初探Web API設計
    • 1-10
      第一章 API設計原則
    • 1-11
      Web API設計要素
    • 1-12
      商業能力
    • 1-13
      產品思維
    • 1-14
      開發體驗
    • 1-15
      API設計＝溝通與交流
    • 1-16
      檢視軟體設計原則
    • 1-17
      模組化
    • 1-18
      封裝
    • 1-19
      高內聚低耦合
    • 1-20
      Resource-Based API設計
    • 1-21
      資源≠資料模型
    • 1-22
      資源≠物件或領域模型
    • 1-23
      在Resource-Based API交換資訊
    • 1-24
      Web API設計原則
    • 1-25
      總結
    • 1-26
      第二章 API設計與團隊合作
    • 1-27
      為什麼需要API設計流程？
    • 1-28
      API設計流程的反模式
    • 1-29
      「抽象泄漏」反模式
    • 1-30
      「下次再改」反模式
    • 1-31
      「孤注一擲」反模式
    • 1-32
      「乏人問津」反模式
    • 1-33
      「API設計優先」方法
    • 1-34
      「API設計優先」與敏捷開發
    • 1-35
      檢視敏捷開發宣言
    • 1-36
      API設計優先中的敏捷性
    • 1-37
      ADDR流程
    • 1-38
      DDD在API設計中的角色
    • 1-39
      API設計與全員參與
    • 1-40
      有效的實施流程
    • 1-41
      總結
    • 1-42
      Part II 尋求一致性
    • 1-43
      第三章 鑑別數位能力
    • 1-44
      確保參與者的共同目標
    • 1-45
      什麼是「數位能力」？
    • 1-46
      聚焦在JTBD
    • 1-47
      什麼是工作故事？
    • 1-48
      工作故事的結構
    • 1-49
      寫出API的工作故事
    • 1-50
      方法一：已知要解決的問題
    • 1-51
      方法二：已知要達成的目標
    • 1-52
      方法三：已知所需的數位能力
    • 1-53
      工作故事中的挑戰
    • 1-54
      挑戰一：太多細節
    • 1-55
      挑戰二：太偏向功能面
    • 1-56
      挑戰三：缺乏使用情境
    • 1-57
      撰寫工作故事的技巧
    • 1-58
      實際的API設計案例
    • 1-59
      工作故事範例
    • 1-60
      總結
    • 1-61
      第四章 產生活動與步驟
    • 1-62
      從工作故事產生活動與步驟
    • 1-63
      從工作故事中產生活動
    • 1-64
      將活動解構成步驟
    • 1-65
      如果需求不明確呢？
    • 1-66
      利用事件風暴求出共識
    • 1-67
      事件風暴怎麼玩？
    • 1-68
      第一步：區分領域事件
    • 1-69
      第二步：建立事件敘述
    • 1-70
      第三步：回顧事件敘述與劃分事件範圍
    • 1-71
      第四步：補充領域資訊
    • 1-72
      第五步：回顧最終的事件敘述
    • 1-73
      事件風暴的好處
    • 1-74
      誰應該來玩？
    • 1-75
      舉辦一場事件風暴
    • 1-76
      準備：準備道具
    • 1-77
      分享：事前說明
    • 1-78
      執行：開始執行
    • 1-79
      總結：找出活動與步驟
    • 1-80
      後續：活動後的建議
    • 1-81
      調整活動流程
    • 1-82
      總結
    • 1-83
      Part III 定義API
    • 1-84
      第五章 界定API邊界
    • 1-85
      避免API邊界的反模式
    • 1-86
      超級多合一API反模式
    • 1-87
      超載API反模式
    • 1-88
      零散小工具API反模式
    • 1-89
      有界語境、子領域與API
    • 1-90
      用事件風暴界定API邊界
    • 1-91
      用活動界定API邊界
    • 1-92
      API的命名與範圍
    • 1-93
      總結
    • 1-94
      第六章 建立API模型
    • 1-95
      什麼是API模型？
    • 1-96
      API Profile結構
    • 1-97
      API建模流程
    • 1-98
      第一步：建立API profile概要
    • 1-99
      第二步：找出相關資源
    • 1-100
      第三步：定義資源階層
    • 1-101
      第四步：加入操作事件
    • 1-102
      第五步：補充操作細節
    • 1-103
      用時序圖驗證API模型
    • 1-104
      評估API優先度與重用性
    • 1-105
      總結
    • 1-106
      Part IV 設計API
    • 1-107
      第七章 REST API設計
    • 1-108
      什麼是REST API？
    • 1-109
      REST是主從式架構的
    • 1-110
      REST是以資源為中心的
    • 1-111
      REST是以訊息為基礎的
    • 1-112
      REST是支援分層式系統的
    • 1-113
      REST是支援Code on Demand的
    • 1-114
      REST的Hypermedia特性
    • 1-115
      何時該選用REST？
    • 1-116
      REST API設計流程
    • 1-117
      第一步：設計資源的URL路徑
    • 1-118
      第二步：將API操作對應到HTTP方法
    • 1-119
      第三步：設定回應碼
    • 1-120
      第四步：撰寫REST API設計文件
    • 1-121
      第五步：分享並獲得回饋
    • 1-122
      決定API的表現格式
    • 1-123
      資源序列化
    • 1-124
      序列化加Hypermedia
    • 1-125
      支援Hypermedia的通用訊息格式
    • 1-126
      語意化的通用訊息格式
    • 1-127
      常見的REST API設計模式
    • 1-128
      CRUD
    • 1-129
      更多的資源生命週期
    • 1-130
      Singleton的資源
    • 1-131
      背景（隊列）工作
    • 1-132
      REST的長跑型互動問題
    • 1-133
      總結
    • 1-134
      第八章 RPC與Query-Based API設計
    • 1-135
      什麼是RPC API？
    • 1-136
      gRPC協議
    • 1-137
      使用RPC的考慮因素
    • 1-138
      RPC API設計流程
    • 1-139
      第一步：識別RPC操作
    • 1-140
      第二步：為RPC操作加入細節
    • 1-141
      第三步：撰寫API設計文件
    • 1-142
      什麼是Query-Based API？
    • 1-143
      理解OData
    • 1-144
      探索GraphQL
    • 1-145
      Query-Based API設計流程
    • 1-146
      第一步：設計資源與圖譜結構
    • 1-147
      第二步：設計Query和Mutation操作
    • 1-148
      第三步：撰寫API設計文件
    • 1-149
      總結
    • 1-150
      第九章 異步API
    • 1-151
      輪詢的問題
    • 1-152
      帶來新局的異步API
    • 1-153
      檢視收發訊息的本質
    • 1-154
      訊息的風格與區域性
    • 1-155
      訊息的組成元素
    • 1-156
      訊息的中介代理
    • 1-157
      點對點訊息發布（隊列模式）
    • 1-158
      扇出式訊息發布（主題模式）
    • 1-159
      訊息串流基礎
    • 1-160
      異步API風格
    • 1-161
      用Webhook傳送通知
    • 1-162
      用SSE推送訊息
    • 1-163
      用WebSocket進行雙向通知
    • 1-164
      gRPC串流
    • 1-165
      挑選異步API實現風格
    • 1-166
      設計異步API
    • 1-167
      命令訊息
    • 1-168
      事件通知
    • 1-169
      帶有狀態變更的事件
    • 1-170
      批次事件
    • 1-171
      事件的排序
    • 1-172
      撰寫異步API文件
    • 1-173
      總結
    • 1-174
      Part V 優化API設計
    • 1-175
      第十章 從API到微服務
    • 1-176
      什麼是微服務？
    • 1-177
      用微服務降低協作成本
    • 1-178
      API與微服務的差異
    • 1-179
      衡量微服務的複雜度
    • 1-180
      自助式的基礎設施
    • 1-181
      獨立的發布週期
    • 1-182
      單團隊管理
    • 1-183
      組織架構與文化衝擊
    • 1-184
      資料所有權的轉移
    • 1-185
      分散的資料管理與治理
    • 1-186
      分佈式系統的挑戰
    • 1-187
      復原性、故障轉移和分佈式事務
    • 1-188
      重構與程式碼共享的挑戰
    • 1-189
      微服務的同步與異步
    • 1-190
      微服務架構風格
    • 1-191
      服務間直接通訊
    • 1-192
      以API為基礎的規劃
    • 1-193
      以模組化單元組成的架構
    • 1-194
      穠纖合度的微服務
    • 1-195
      將API解構成微服務
    • 1-196
      第一步：識別出可能的微服務
    • 1-197
      第二步：在API時序圖中加入微服務
    • 1-198
      第三步：用MDC定義細節
    • 1-199
      額外的設計考量
    • 1-200
      轉換成微服務時的考量
    • 1-201
      總結
    • 1-202
      第十一章 優化開發體驗
    • 1-203
      建立擬真API
    • 1-204
      建立靜態API
    • 1-205
      建立原型API
    • 1-206
      用README模擬
    • 1-207
      提供輔助套件與SDK
    • 1-208
      輔助套件的供給模式
    • 1-209
      輔助套件的版次管理
    • 1-210
      輔助套件的文件與測試
    • 1-211
      提供CLI工具
    • 1-212
      總結
    • 1-213
      第十二章 API測試策略
    • 1-214
      驗收測試
    • 1-215
      自動化安全測試
    • 1-216
      運行監控
    • 1-217
      API Contract測試
    • 1-218
      能加速測試的工具
    • 1-219
      API測試的挑戰
    • 1-220
      建立API測試的必要性
    • 1-221
      總結
    • 1-222
      第十三章 撰寫API設計文件
    • 1-223
      API文件的重要性
    • 1-224
      API描述文件的格式
    • 1-225
      OpenAPI
    • 1-226
      API Blueprint
    • 1-227
      RAML
    • 1-228
      JSON Schema
    • 1-229
      以ALPS製作API Profile
    • 1-230
      用APIs.json增進API的可探知性
    • 1-231
      在文件添加範例程式
    • 1-232
      優先提供入門使用範例
    • 1-233
      用工作流程範例豐富文件內容
    • 1-234
      提供錯誤案例與生產環境案例
    • 1-235
      從文件進化成開發者網站
    • 1-236
      利用開發者網站擴大API採用率
    • 1-237
      優質開發者網站的構成要素
    • 1-238
      有效的API文件
    • 1-239
      問題一：你的API如何解決我的問題？
    • 1-240
      問題二：API的操作各自負責什麼？
    • 1-241
      問題三：我要怎麼開始呢？
    • 1-242
      API文件中技術寫作者的角色
    • 1-243
      開發者網站的MVP
    • 1-244
      第一階段：MVP
    • 1-245
      第二階段：持續優化
    • 1-246
      第三階段：聚焦於成長
    • 1-247
      建立開發者網站的工具與框架
    • 1-248
      總結
    • 1-249
      第十四章 API的改版規劃
    • 1-250
      改版對API帶來的衝擊
    • 1-251
      分析新舊版API差異
    • 1-252
      決定對API用戶較好的選項
    • 1-253
      改版策略
    • 1-254
      建立在信任基礎上的改版
    • 1-255
      API版次策略
    • 1-256
      常見的非破壞性改版
    • 1-257
      破壞相容性的改版
    • 1-258
      API的版次與修訂版次
    • 1-259
      API的版次區別方法
    • 1-260
      API改版的商業面考量
    • 1-261
      API的退場
    • 1-262
      制定退場政策
    • 1-263
      退場的公告
    • 1-264
      建立API穩定性聲明
    • 1-265
      總結
    • 1-266
      第十五章 API防護
    • 1-267
      潛在的危害
    • 1-268
      API防護機制
    • 1-269
      API防護元件
    • 1-270
      API閘道
    • 1-271
      APIM
    • 1-272
      服務網格
    • 1-273
      WAF
    • 1-274
      CDN
    • 1-275
      智慧型API防護
    • 1-276
      API閘道拓撲
    • 1-277
      API管理主機的選擇
    • 1-278
      API網路流量來源的考量
    • 1-279
      拓撲模式一：API閘道直連API
    • 1-280
      拓撲模式二：API閘道導給不同的服務
    • 1-281
      拓撲模式三：多重API閘道
    • 1-282
      IAM
    • 1-283
      密碼與API密鑰
    • 1-284
      API Token
    • 1-285
      以參照傳遞Token vs.以值傳遞Token
    • 1-286
      OAuth 2.0與OpenID Connect
    • 1-287
      自行建置API閘道前的考量
    • 1-288
      理由一：百密一疏的安全性
    • 1-289
      理由二：事倍功半的努力
    • 1-290
      理由三：並非一蹴可及的成果
    • 1-291
      那用現成套件如何？
    • 1-292
      總結
    • 1-293
      第十六章 繼續在API設計的航道上
    • 1-294
      建立API風格指南
    • 1-295
      鼓勵依循風格指南的手段
    • 1-296
      挑選風格指南的調性
    • 1-297
      風格指南製作小技巧
    • 1-298
      提供多種API風格
    • 1-299
      進行API設計檢討
    • 1-300
      從文件檢討開始
    • 1-301
      確認標準與設計一致性
    • 1-302
      檢查自動化測試的涵蓋範圍
    • 1-303
      加入可試用特性
    • 1-304
      發展重用文化
    • 1-305
      從起點展望未來
    • 1-306
      附錄
    • 1-307
      HTTP入門
    • 1-308
      索引
    • 1-309
      版權頁
    • 1-310
      封底

    常見問答

    您可以透過手機、平板或是電腦登入 HiSKIO 平台，在【我的學習】＞【我的書籍】頁面，選擇想看的電子書。

    猜你喜歡

    用戶評價

    | 收集中

    銷售方案