API 是什麼?

API，全名 Application Programming Interface (應用程式介面)，簡單來說，是品牌開發出的一種接口，讓第三方可以額外開發、應用在自身的產品上的系統溝通介面。

來看個短短的、清楚直白的敘述影片：API 就是你的餐廳服務生💁

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FzvKadd9Cflc%3Ffeature%3Doembed&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DzvKadd9Cflc&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FzvKadd9Cflc%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

以實際應用的範例而言，Google Map API 就很好理解了，常常可以在各式不同的網站看見 Google Map 應用，很多都是接 Google Map API 的範例，營運考量上，有可能 API 會限制一定使用流量以內免費，超過即收費，Google map 也是如此。

點我查看 Google Maps API 收費標準

在 RESTful API 之前，要再理解一下 HTTP，HTTP 是一種協定，全名 Hypertext Transfer Protocol（超文本傳輸協定），網路世界其實就分為客戶端、伺服器端，舉例說，客戶端就是我，伺服器端就是 Yahoo，我要看 Yahoo 的首頁，我就是向 Yahoo 的伺服器端傳送了這個要求，Yahoo 再回應資源給我。為了讓要求和回應統一規範，就有了 HTTP。

舉例，假設我要吃滷味：

• 在瀏覽器輸入 Yahoo 網址，按下 enter，送出 request (跟老闆說我要切兩塊百頁豆腐)
• 伺服器收到 request 檢查該網址是否存在(老闆轉身看百頁豆腐還有沒有)
• 伺服器發 response 回來(百頁豆腐切好了)

跟老闆點餐的方式，有一定的規範跟方式，像是我一定要用講的，不可以用比的，我要說中文，不可以說英文，這就是 HTTP 協定。

如果伺服器發現網址不存在(老闆發現百頁豆腐賣完了)，就會回傳 HTTP status code 狀態碼 404：

狀態碼又會再分為下幾種：

2xx = Success（成功）
3xx = Redirect（重定向）
4xx = User error（客戶端錯誤）
5xx = Server error（伺服器端錯誤）

在 HTTP 中，會有很多種 method 做為請求的方法，常用的幾個動作分別為：GET / POST / PUT / DELETE，正好會對應到資料庫基本操作 CRUD 增刪查改。

CRUD 為 Create(新增)、Read(讀取)、Update(更新)與Delete(刪除)的縮寫

那 RESTful API 又是什麼?

先來看是誰發明的↓

REST，全名 Representational State Transfer( 表現層狀態轉移)，他是一種設計風格，RESTful 只是轉為形容詞，像是 peace 和平這名詞，轉成形容詞是 peaceful，RESTful 則形容以此規範設計的 API，稱為 RESTful API。

先用白話來說，以剛剛 API 影片中的餐廳服務生為例，如果使用一般的 API 點菜，我要加點、查看已點菜色、修改已點菜色、取消已點菜色，都需要不同的服務生替我服務，可能加點的服務生是 John、查看已點菜色是 Annie….等，RESTful API，就是讓這些動作，都可以由同一位服務生完成。

RESTful API 主要由三種元件組成：

1. Nouns 名詞：定義資源位置的 URL，每個資源在網路上都會有唯一的位置，就如每戶人家都有唯一的地址一樣。
2. Verbs 動詞：對資源要做的動作。
3. Content Types 資源呈現方式：API 資源可以以多種方式表現，最常用的是 JSON，較輕，也較好處理。

一般的 API，可能會是這樣：

獲得資料GET    /getData
新增資料POST   /createData
刪除資料DELETE /deleteData/1

不同公司，不一樣的工程師，設計的名稱都會不一樣，沒有統一的命名方式，造成在引用各家 API 時，都需要詳讀 API 文件，理解所有設計命名規則後，才可使用。

若以 RESTful API 風格開發的話：

獲得資料GET     /data
新增資料POST    /data
刪除資料DELETE  /data/1

就是用一個唯一的 URL 定位資源，將動作藏在 HTTP 的 method 裡面。

所以使用 RESTful 風格設計的 API，就有了以下幾種優點及限制：

1. 有唯一的URL表示資源位置，統一的 API 接口。(Uniform Interface)

2. 無狀態。(Stateless)

RESTful 的狀態，意即 HTTP 的請求狀態，一般 Web 服務中，Server 端和 Client 端交互的資訊，會存在 Server 端的 Session (例如：已登入狀態)，在 Client 端再次發送請求的時候，Server 端透過保存在 Server 端的 Session，去執行 request。無狀態的意思，即 Client 端自行保存狀態，在請求 Server 的時候，一併附上給 Server 端，Server 端無保存 Client 端的狀態資訊。

舉例來說，可能在用戶登錄系統時，Server 產生 token 紀錄 user 已登錄系統，然後把 token 還給 Client，在 Client 再次發送請求的時候，把 token 一起發給 Server，這樣 Server 就知道這一個 Client 是已經處於登錄的狀態。

意即所有的資源都可以 URI 定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化，資源相互的依賴性降低。

舉一個白話一點的例子：查詢員工工資：
第一步：登錄系統。
第二步：進入查詢工資的頁面。
第三步：搜索該員工。
第四步：點擊姓名查看工資。

這樣的操作流程就是有狀態的，查詢工資的每一個步驟都依賴於前一個步驟，只要前置操作不成功，後續操作就無法執行。如果輸入一個URL就可以直接得到指定員工的工資，這種情況就是無狀態的，因為獲取工資不依賴於其他資源或狀態，這種情況下，員工工資是一個資源，由一個 URL 與之對應可以通過 HTTP 中的 GET 方法得到資源，這就是典型的 RESTful 風格。

3. 可更高效利用快取來提高回應速度 (Cachable)

在 server-side，GET 過的資源，如果沒有被變更過，可以利用 cache 機制減少 request。
在 client-side，透過 client 端 cache 紀錄 cache 版本，若向 server 要求資源時發現 server 最新版與 cache 相同，則 client 端直接取用本地資源即可，不需要再做一次查詢

4. 分層系統架構 (Layered System)

5. 客戶端服務器分離 (Client-Server)

6. 充份利用 HTTP protocal(GET/POST/PUT/DELETE) (Manipulation of resources through representations)

7. 可執行程式碼的設計，像是 JavaScript（非必要實作項目） Code-On-Demand (optional)

參考文章：
https://zh.wikipedia.org/wiki/%E8%A1%A8%E7%8E%B0%E5%B1%82%E7%8A%B6%E6%80%81%E8%BD%AC%E6%8D%A2
https://tw.alphacamp.co/blog/2016-10-25-coding-basics-for-marketers-1
https://ithelp.ithome.com.tw/articles/10157431
https://www.itread01.com/content/1544242329.html
https://progressbar.tw/posts/53
https://blog.csdn.net/hjc1984117/article/details/77334616
https://www.zhihu.com/question/28557115
https://blog.csdn.net/hjc1984117/article/details/77334616
http://www.ruanyifeng.com/blog/2011/09/restful.html
https://blog.toright.com/posts/5523/restful-api-%E8%A8%AD%E8%A8%88%E6%BA%96%E5%89%87%E8%88%87%E5%AF%A6%E5%8B%99%E7%B6%93%E9%A9%97.html
https://blog.csdn.net/Jmilk/article/details/50461577
https://blog.csdn.net/matthew_zhang/article/details/63410421

資料來源：https://medium.com/itsems-frontend/api-%E6%98%AF%E4%BB%80%E9%BA%BC-restful-api-%E5%8F%88%E6%98%AF%E4%BB%80%E9%BA%BC-a001a85ab638

歐盟-美國隱私護盾是監管歐盟和美國之間出於商業目的跨大西洋交換個人數據的法律框架。^[1]其目的之一是使美國公司能夠根據旨在保護歐盟公民的歐盟隱私法更輕鬆地從歐盟實體接收個人數據。^[2]歐盟-美國隱私護盾在獲得歐盟委員會批准後於 2016 年 7 月 12 日生效。它取代了被歐洲法院宣布無效的國際安全港隱私原則2015 年 10 月。^[3]歐洲法院於 2020 年 7 月 16 日宣佈歐盟-美國隱私護盾無效，案件稱為Schrems II。^[4] 2022 年，美國和歐盟領導人宣布已同意一個名為跨大西洋數據隱私框架的新數據傳輸框架，以取代隱私盾。

資料來源：https://en.wikipedia.org/wiki/EU%E2%80%93US_Privacy_Shield

歐盟法院認為美國並無法提供與歐盟一致的隱私保障，特別是歐盟民眾的個資可能受到美國情報機構的窺探，因而決定廢除《隱私盾》（Privacy Shield）資料傳輸保護協議

歐盟法院（CJEU）在7月16日廢除了歐盟與美國之間的《隱私盾》（Privacy Shield）資料傳輸保護協議，這是由歐盟執委會（European Commission，EC）、美國商務部及瑞士在2016年所建立的框架，雙方同意將基於歐盟的隱私法令，簡化美國企業將歐洲民眾資料傳送到美國的流程，以支持跨大西洋貿易。然而，CJEU認為美國並無法提供與歐盟一致的隱私保障，特別是歐盟民眾的個資可能受到美國情報機構的窺探，因而決定將它廢除。

其實為了方便歐盟與美國之間的個資傳輸，雙方在2000年時曾推出《安全港隱私準則》（Safe Harbour Privacy Principles），但一名奧地利的隱私權捍衛人士Max Schrems在2011年時，於2個月內接連向愛爾蘭的資料保護局提出22項隱私控訴，指控臉書並未好好保障他的隱私，再加上美國吹哨者Edward Snowden在2013年時爆料美國國安局的Prism計畫可監控美國9大科技公司的通訊，讓Schrems針對PRISM再度提出第23次的控訴，雖然Schrems在愛爾蘭的訴訟案全都以失敗收場，卻促使愛爾蘭法院把有關《安全港隱私準則》的問題轉給了歐盟法院。

Schrems繼續在2014年對臉書發動集體訴訟，而歐盟法院也開始在2015年正視《安全港隱私準則》，認為是該準則讓Prism計畫得以實現，於是在同年廢除了《安全港隱私準則》。

歐盟與美國接著在2016年提出《隱私盾》以取代《安全港隱私準則》。不過，Schrems並不罷休，在2018年又控告了臉書侵犯隱私，同時宣稱《隱私盾》依然無法完全保障歐洲民眾的隱私權，這一次，歐盟法院再度廢除了《隱私盾》。

歐盟法院解釋，居住在奧地利的Schrems從2008年以來就是臉書的用戶，但臉書卻把他的部份或全部資料從愛爾蘭（臉書的歐洲總部）轉到美國處理，Schrems認為美國的法令並未提供足夠的隱私保護，因此要求禁止資料的轉移。另一方面，美國法令對於公家機關存取歐洲民眾資料的保護有限，並不符合歐盟要求移轉資料的第三方，必須具備與歐盟隱私法令（GDPR）同等級保護的規定，因而認定《隱私盾》協議是無效的。

值得注意的是，此案並未波及美國與歐盟之間的必要資料傳輸，像是電子郵件、傳訊、在美國平臺上預訂飯店，或是其它標準的商業交易，也不影響那些不含個人資訊的資料傳輸，主要波及的是外包業務，例如為了經濟之故，把個資存放在較便宜的美國服務上，或者是傳到美國以方便處理等業務。

此外，Schrems所指控的協議並不只歐美之間的《隱私盾》，他還指控了歐盟與任何第三方國家之間有關個資傳輸的《標準合約條款》（Standard Contractual Clauses，SCCs），儘管外界質疑SCCs與《隱私盾》一樣，都可能讓歐洲民眾的個資落入美國的監控，但這次歐盟法院放行了SCCs。

儘管微軟很快在歐盟法院裁決出爐的同一天就發表了聲明，表示該公司同時提供了《隱私盾》與《標準合約條款》的雙重保障，因此，透過微軟雲端服務在歐盟及美國之間傳遞資料的商業客戶，並不會受到此案的影響。

然而，非營利的歐洲數位權利中心（European Center for Digital Rights，ECDR）認為，此一裁決將衝擊所有在歐盟設立子公司的美國企業，這些企業必須確保歐洲民眾個資在內部的流通符合GDPR規範，例如把個資傳送到其它隱私法令更嚴格的地方，而非美國。

ECDR強調，歐盟法院放行SCCs是因為它涉及美國之外的其它國家，這些國家可能具備與GDPR同等級或更嚴格的隱私法令，並不代表美國業者可利用SCCs把歐洲民眾的個資傳到美國，因為根據歐盟法院的意見，撤銷《隱私盾》的主因在於美國對情報需求的監控法令不夠嚴格，也看不出對監控權力的限制，看起來比較像是只要是落入美國政府監控範圍的企業不只失去了《隱私盾》，也無法再使用SCCs。

資料來源：https://www.ithome.com.tw/news/138915

VPN就是透過tunneling技術, 把公眾/共用網路當作(模擬成)網路線來連接公司的電腦及網路. 由於使用公眾/共用網路, 因此必須搭配安全服務(如身份驗證, 金鑰交換, 加密, 完整性控制)才能安全地在tunnel上傳輸資料.
VPN = 建立私有通道(tunneling) + 提供安全服務(security services)
https://wentzwu.com/2022/05/18/vpn-tunneling-and-security-services/

-代碼倉庫：git
顧名思義，整合測試結合了代碼單元、模組或子系統並對其進行測試。在託管代碼儲存庫的服務器上進行整合測試是很常見的，例如 git 服務器。
在持續整合設置中，當滿足構建標準（夜間構建或新代碼簽入）時，服務器開始構建代碼並運行簽入代碼存儲庫的所有單元測試。如果構建或任何測試失敗，則會向相關方發送通知以解決問題，直到一切正常；這種迭代過程稱為回歸測試。

模組或子系統通常通過所謂的 API（應用程序編程接口）相互通信。API 測試沒有用戶界面，依賴於測試工具來提供數據作為輸入並接收結果作為輸出。Fuzzer 是Fuzz 測試中使用的工具，可幫助生成隨機測試數據以饋入接口測試。

系統測試在整合測試完成後開始，例如壓力測試、性能測試、安全測試等。大部分系統測試任務都可以自動化。一旦自動化任務完成，測試人員就會參與進來。他們根據包含一個或多個場景或用例的測試用例來測試系統。誤用案例基本上是採取攻擊者觀點的用例。

參考
. 誤用案例
. 整合測試
. 系統測試

資料來源： Wentz Wu QOTD-20211024

-XP 實踐（來源：https ://twitter.com/CharlotteBRF ）
結對編程是眾所周知的極限編程 (XP) 實踐之一。這也是一種實時代碼審查的實踐；同行開發人員在其他開發人員編寫代碼時即時監控和審查。
命名約定（Naming convention）、SQL 注入（SQL injection）和邏輯炸彈（logic bomb）在源代碼級別很容易被發現。然而，像死鎖這樣的競爭條件通常會不時發生在運行時（動態測試），並且很難在設計時識別（靜態測試）。競爭條件是由多線程、並行編程或多用戶環境導致的並發問題。
參考
. 代碼審查清單——執行有效的代碼審查
. 任何開發人員都應該知道的 4 種代碼審查類型
. 五種審查

資料來源： Wentz Wu QOTD-20211023