Web API 設計最佳作法 - Azure Architecture Center
🗒️ Logos 筆記：
✏️ 摘要－設定 http/ https header 以維持資料的保密性與一致性 (文末略提及可用性，惟著墨較少)。
🤔 問題－無法理解 hooks/event propogation 整段。這裡的 event propogation 很明顯不是討論 DOM 的那個冒泡事件。
Emily/ KK: RESTful API 是針對單一資源做操作，所以當資源發生變更時，這個變更需要通知 developer 這個變更發生。
📒 Logos 管釐爾雅：
1. RFC (Requests for Comments)－看起來像是記錄通訊協定應該遵守那些規範的標準文件。
https://www.cyut.edu.tw/~ckhung/l/rfc.php
https://juejin.cn/post/6844903716051484679
2. Idempotency 冪等性－某個 API 具備冪等性 iff 該 API 呼叫 n 次的結果與呼叫 1 次相同。
https://william-yeh.net/post/2020/03/idempotency-key-test/
(推薦這篇！🔥)
3. Etag－在 header 中標誌網頁版本的標籤。
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/Headers/ETag
4. Erlang－專精於平行處理與熱更新的程式語言。(!?) https://www.ithome.com.tw/node/48785
5. Clojure－動態的、強類型、執行在 Java 虛擬機（JVM）上的 Lisp 方言。
https://ithelp.ithome.com.tw/articles/10184776
6. BASIC Auth/ OAuth－認證是個超級大坑......
https://carsonwah.github.io/http-authentication.html
(上述文章含 Replay Attack 簡介與解法。推薦！🔥)
另外，參考 Web 實驗室 Youtube 頻道
「成為看起來很強的後端」系列 8, 16-28
7. Kafka－
8. RabbitMQ－看來是利用多佇列維持 HA 的套件？
https://kucw.github.io/blog/2020/11/rabbitmq/
🗒️ Stan note:
Idempotency: 執行N > 0次 與執行1次都是同樣結果，在REST API的操作行為下
這些不同的地方在於return form rather than in the return value
ref: https://nordicapis.com/understanding-idempotency-and-safety-in-api-design/
status code:
於現行許多API status codes不合RFC的規範，經常使用200 + error messages(我以前常用的是兩層statusCodes, 最外層200 內層資料自定義statusCode)，但如需open須依照RFC(RFC 7231)規範．
ref: https://datatracker.ietf.org/doc/html/rfc7231#page-48
透過單一入口銜接message queue(兔子MQ, Kafka)，做佇列處理→ 但consumer有可能根據exchange 處理順序的不同 → 間接影響到api Idempotency