20/03/2024
接下來跟大家介紹六個常見的API架構、方法、協議
1. SOAP(Simple Object Access Protocol)
這是一項較舊也相對較成熟的API協議，由W3C(全球資訊網協會)提出與維護，可以讓不同程式語言或OS的程式進行溝通。
傳送到SOAP API的Application Layer Protocal可以是HTTP (for瀏覽器), SMTP (for email), TCP等等，但回傳的資料格式必須是XML格式(一個人類、機器都可讀的標記語言)。
因為SOAP是一個Protocal，所以有較多複雜與冗長的規要遵守，它可能會增加軟體的載入時間與開發週期，也代表SOAP不適合用於輕量的專案開發。因其具有較高的安全性，故通常用於銀行業處理金錢交易相關服務。
2. RESTful API (Representational State Transfer API)
RESTful是目前最流行的API設計方法，它並非是一項協議，而是一套架構原則，用於輕量化的網站服務或是手機應用。當今許多網站都依照RESTful來設計API，像是Youtube、X。當RESTful API收到HTTP請求時， API可以以HTML, XML, plain text, JSON資料格式進行回傳。開發者通常偏好用JSON(一種儲存訊息且機器和人類都可讀的檔案類型)進行回傳，除了因為它可以被任何程式語言進行讀取，JSON輕量化的特性也受到大家喜愛。但RESTful不適用於需要及時資料傳輸的服務。
遵守以下準則設計的API會被稱作RESTful API:
(1) Stateless
每個request應該要包含了解及執行request的必要資訊，server不會在requests間儲存client的狀態，session資料會被儲存在client，
(2) Client-Server architecture
client和server是兩個獨立的個體，通過網路進行溝通。client負責UI與UX設計，而server端負責商業邏輯的實現與數據存儲。
(3) Cacheable
server給出的responses應該是可以被client快取的，可以用於節省server負擔。
(4) Layered System
階層式系統可以讓不同layer擔任不同的角色，有利於system design的可擴展性。
3. GraphQL
GraphQL不只是一種API架構，也是一種Query Language，允許Client項資料庫請求特定資料，可以避免over-fetching(每次request拿太多資料，導致效能的浪費)與under-fetching(每次endpoint拿不完所有資料，需要再call第二次endpoint)。GraphQL 可以讓client-server間通訊變得更加高效，它是由Facebook所開發，因為Facebook每天需要服務上百萬的用戶，所以高效能的API對其而言非常重要。GraphQL也被Shopify、Github所採用。
4. gRPC
gRPC是一種現代且高效能的API架構，由Google在2015年所提出，使用http/2所以比一般http/1.1更快速，此外其使用Protocal Buffer作為介面定義語言(interface definition language, IDL)，因此在開發上可以更快速的在不同的語言、服務上互動。有別於一般open api使用url、http methods、參數等在client與server間互動，gRPC的IDL則更為直觀明確，"client與server端皆須使用同一份 .proto 檔案作為介面"。很多公司打造微服務(microservice)架構會使用gRPC。Netflix就使用gRPC作為server間溝通的方式，以應付它們巨量的流量傳輸。gRPC對瀏覽器的支援較少，故不適合獨立開發者用它來作為web programming 的API架構。
5. WebSocket
WebSocket是一種基於 TCP 的全雙工網路傳輸協定。此技術被廣泛運用在視訊通話、多人線上遊戲，這些應用通常要求低延遲且即時的資料傳輸。
早期的推播技術、訊息即時更新技術，都是使用 輪詢(polling)的方式，但這種作法會需要大量的請求和回覆，造成同樣的標頭(header) 重複使用，而且用的是很肥的 HTTP 標頭，實際傳輸的內容大小可能比標頭還小，因此這種作法會佔據大量傳輸資源(尤其是需要短時間不斷更新的功能)，於是 WebScocket 技術就誕生了。
在 WebSocket 技術中，Server 和 Client 之間會先透過 HTTP 協定 握手(handshake)建立一個 TCP 通道(類似從 server 拉水管到 client)，之後傳輸訊息就可以直接透過通道，而不必再使用 HTTP 協定的標頭，而且他是全雙工，所以 Server 可以主動向 Client 傳輸資料。
WebSocket 使用的具體過程為，Client 先和 Server 發起連線，當成功連線後 Client 可以訂閱(subscribe) 代理(broker)，當 Server 發送訊息到代理時，有該代理會將訊息傳給有訂閱的 Client。在建立連線時，Client 會有特定的 Session 被 Server 儲存，所以 Server 能透過這些 Session 來確定各個連接的 Client 是誰，也就能做到指定對象的傳輸。
6. Webhook
webhook暱稱叫做reverse APIs or push APIs，但它並不是一個API，它是一個HTTP-based且由event所驅動的的callback function，它非常的輕量化，可用於兩個API間的通訊。
在傳統的web server設計中,，假設專案A想要獲取專案B的資料，通常B需要提供一個API，然後A去請求B的API，從而獲得資料，這樣的過程我們稱之為"拉"data。
假設今天A需要實時獲取到B的最新資料，在傳統做法中，我們需要不停的去向B做Poll(輪詢)操作，以便獲取到最新數據，但這樣的效率和性能都非常低下，通過webhook機制來設計，可以讓A提供一個webhook url，每次B新增資料(看做一個event)時,便會向A的hook地址進行請求，A收到B的請求，然後對數據進行處理。比較有名的line bot、GitOps便是使用webhook技術。
這個網址有webhook更完整的介紹:
https://www.redhat.com/en/topics/automation/what-is-a-webhook
