「所有架構都來自於設計，但並非所有設計都能成為架構，架構來自於一系列重要的設計決策，這些決策塑造了一個系統的形式及功能」

「軟體開發者總是花費大量的時間在學習，學習那些他們未知的東西，這其他工作截然不同，因為我們的每一次總是我們的第一次（儘管在外人看來都是在敲鍵盤）。」

API 設計要素

  • 商業能力
  • 產品思維
  • 開發體驗 (DX)

API 設計 = 溝通與交流

Resource-Base API 迷思

  • 資源不等於資料模型(database table)
  • 資源不等於物件或領域模型 (不等於程式的物件)

API 設計原則

  • 設計 API 不要孤軍奮戰，要成就霸業需要眾志成城
  • API 設計應該是目標導向的，聚焦於目標並確保對他人是有價值的
  • 根據需求決定 API 設計，完美的 API 風格是不存在的，應該根據需求決定API風格，不碖是 REST, gRPC, GraphQL
  • API 最重要的 UI 就是文件，他應該擺在第一順位
  • API 是永存的，設計時需仔細規劃，而後加以迭代改進，才能讓API 保持穩定與彈性

API Design First

首先需要確認目標、弄清楚 API 目標及目的為何，而不是盲目開始寫程式

  • 探索
  • 設計
  • 製作原型 (Prototype API or Mock API)
  • 交付
  • 上線

敏捷宣言

  • 最優先是滿足客戶需求
  • 歡迎改變需求、甚至到開發後期也是
  • 經常交付可用的軟體
  • 業務人員和開發者必須天天一起工作
  • 可用的軟體是最主要的進度量測方法
  • 持續追求優越的技術與優良的設計，以強化敏捷性
  • 精簡：或最大化未完成工作量之技藝

API 設計流程 ：ADDR

  • Align 對齊
  • Define 定義
  • Design 設計
  • Refine 優化

商業能力：企業組織為維持市場競爭力與獲利所具備的能力模型，如產品設計、產品製造、客戶服務都是商業能力的一環

數位能力：企業組織提供自動化機制的能力模型

JTBD: jobs to be done, 在建構產品與服務時，明確知道必須完成的事項。圍繞在用戶有哪些問題、解決問題需要完成的哪些事項、解決問題之上的整體目標等等的課題

Job Story: When , I want to , so I can

事件風暴：好處可以為我們事件建立「模型」

REST API

  • 一系列的架構性約束與約定
    • 主從式架構、以資源為中心、以訊息為基礎、支援分層式系統、支援 Code on Demand、Hypermedia 特性 (可以在 API 狹帶其他相關資訊 例如下一頁等等/ HATEOAS)
  • REST 從來不只是 CRUD
    • JSON 和 CRUD 只是 REST 其中常用的設計要素
  • 適用於粗粒度的訊息交換

RPC 與 Query-Based API

RPC

  • 特徵主客端高度綁定、高度耦合，如果改動則客戶端也要改
  • 序列化格式是死的
  • 瀏覽器需要增加其他機制才能互動
  • 一般來說適用於全端自主開發的團隊，如果是主客端分開開發則需要保持兩端的 RPC 介面一致

Query-Based API (一隻 API 打天下)

  • OData 和 GraphQL
  • OData 以 REST 為基礎，允許以類似 SQL 的方式進行資料查詢操作
  • GraphQL
    • 只用到 GET 和 POST，具體查詢使用其查詢語言撰寫並且也能自定義自己要回覆的格式

異步 API

  • 輪詢
  • Webhook
  • SSE: EventSource
  • Websocket
  • grpc 串流
  • 中介代理：例如 RabbitMQ , AcativeMQ
  • pub-sub 模式

微服務

各自部署的小元件、一個微服務只負責少量的數位能力，每個微服務綜合起來就是一個就是個複雜的系統。 ⇒ 分散式系統的挑戰

不要低估導入微服務帶給組織文化上的衝擊，從原本的以產品或專案為單位的治理模式轉移到以微服務為單位的治理模式的衝擊是巨大的，過往的權資劃分與跨團隊的協調模式都要重頭來過，這是在導入微服務前必須要考慮到的，一且輕忽，那所謂的複雜度不僅不會降低，還會從虛擬的程式碼蔓延到實證的組織文化上。

你真的需要微服務嗎？