System Design 101
Ting 2024/03/13
WHY Need HTTP Status Codes?
用戶輸入了無效網址時，可以讓用戶明確地知道
該網址資源不存在，而不是獲得一個模糊的錯誤訊息。（404 Not Found）
開發人員可以根據不同的情況進行適當的錯誤處理和故障排除。（500 Internal Server Error表示伺服器遇到內部錯誤，401 Unauthorized表示需要身份驗證但未提供有效認證資訊。）
HTTP狀態碼是伺服器(Server side)對於客戶端(Client side)請求的回應，提供一種標準化的方式來溝通伺服器的處理結果。客戶端可以透過狀態碼得知伺服器的回應，並根據不同的狀態碼進行相應的處理。
2 - Successful
200 OK
請求成功，伺服器正確回應請求
3 - Redirection
302 Found：當訪問一個網址，但該網址已被重定向到其他網址
4 - Client Error
401 Unauthorized：試圖訪問需要登錄的頁面，但未提供正確的登錄資訊
404 Not Found：請求的資源在伺服器上找不到
5 - Server Error
502 Bad Gateway 當用戶端向伺服器發送請求時，中介者伺服器無法從上游伺服器（通常是網頁伺服器）獲得有效的回應
WHY Need Webhook?
讓不同的應用程式之間實現即時的資訊交換和數據同步
當某個事件發生，Webhook可立即通知接收方，而不需要等待定期輪詢（polling API）或等待回應。
Webhook觸發自動化流程，例如在提交表單後自動發送電子郵件，或更改資料庫中的內容。
Webhook可用於將數據從一個應用程式同步到另一個應用程式，例如將電子商務網站的訂單同步到庫存管理系統中。
Webhook可以用於將數據傳送到分析工具中。例如將Google Analytics中的事件數據傳送到第三方分析工具，進行更深入的分析。
例子
- Polling
支付服務向payment service provider (PSP)發送付款請求後，
不斷向PSP詢問付款狀態。
經過幾輪之後，PSP終於回覆狀態。
缺點：
- Webhook （伺服器向客戶端發送 HTTP 請求）
我們可以向外部服務註冊webhook。當有請求更新時，call back某個 URL 。
當 PSP 完成處理後，invoke HTTP request來更新付款狀態。這樣支付服務不再需要浪費資源來輪詢支付狀態。
- 可以設定排程 （每小時檢查是否更新付款狀態。 ）
官網和Sass平台溝通，實作資訊交換
Eg.
1. 使用Webhook，當客戶在官網付款成功後Trigger API
2. 將付款人的名稱和購買方案寄到公司email 信箱
3. 在Sass平台註冊幫付款成功的使用者註冊帳號密碼
4. 公司email 信箱寄信給使用者帳號密碼
當客戶在官網付款成功後 =>
Trigger Frontier API幫客戶在平台建立帳號密碼
Code-first vs API-first
（著重於應用程式的邏輯和功能）
先撰寫應用程式的代碼，然後再設計和開發相關的API。
開發人員通常會先考慮應用程式的邏輯和功能，然後再根據這些需求來設計API。
好處：開發人員可以更容易地控制和調整應用程式的邏輯，並且可以根據需求進行靈活的開發。
WHY API-first?
REST API vs. GraphQL
REST API（Representational State Transfer API，表現層狀態轉換API）
使用HTTP協議來進行通信，通過URL定位資源，使用HTTP方法（如GET、POST、PUT、DELETE）來操作資源，使用不同的狀態碼和資源表述來表示操作結果。
流程：
WHY need GraphQL?
GraphQL a server-side runtime and query language for your API
由Facebook開發的查詢語言和執行引擎，允許客戶端精確地指定需要的資料，並返回符合指定結構的結果。
與REST API相比，GraphQL具有以下優勢：
RESTful 最大的好處之一就是遵循 HTTP 規範，因此只要單一 end point 有問題，就可以透過 statue code (5xx) 知道問題發生。
而 GraphQL 如果在 client 端發生問題的話，也只會回 200，所以對於錯誤捕捉可能需要花費額外的功夫，例如去監聽 client side 回傳回來的 message，但這個也需要 client 去額外處理。
Thank You!