JSON事件驅動與RESTful API比較
我很確定事件驅動已經是一個大問題，並且會變得更大。事實上，事件是JSON blob，並且通常我們希望它們在計算機程式中更容易使用。我以前也寫過關於很難指定JSON格式化文章，也有關於無模式的訊息處理。事實證明，JSON Schema世界雖然有好訊息，但問題遠未解決。
據我所知，實際上只有兩種方法可以將軟體連線在一起：API呼叫（我傳送請求並等待您的響應）和事件（我觸發了一條訊息，無論是誰，它都可以執行任何操作做）。後者的一個常見變體是，與事件一起，你傳送一個回撥地址，可能希望活動消費者給你回撥。
API很簡單，對程式設計師來說很自然，因為我們都在成長，呼叫子程式和函式。有時候這種思維方式在網路上執行得很好，就像我向你傳送一個HTTP請求，其中包含你需要為我做一些事情的所有事情，我等待回覆說你做了什麼。但是API存在問題，最糟糕的是它們構成緊密耦合; 你和我必須保持同步，如果有時我發出請求的速度比你能處理的如果要快一點，那麼就糟糕了。
事件使耦合更加鬆散。顯然，它留下了插入緩衝的自然位置; 如果我領先於你，那沒關係，訊息可以在傳輸過程中得到緩衝，最終當我放慢速度時你會趕上來，這很好。
更寬的鬆耦合留下空間來處理傳輸中的大量其他有用的東西：匯出，記錄/審計，轉換，分析和過濾，僅舉幾例。我認為所有整合任務的很大一部分自然適合事件驅動的程式碼，而不是API。所以，我關心的是讓它變得簡單。
合同和模式 ·API通常具有自己合同和模式。在強型別程式語言中，它們是詳細而嚴格的，在編譯時進行驗證，以便在執行時快速，可信地執行。對於RESTful API中，我們有類似的事情如/OpenAPI的，GraphQL 提供了另一種方法。
在面向事件的系統中的合同則完全不同，但有它們總比沒有好。我聽說有人寫這種軟體要求“模式”，我認為他們其實真正想要的是：
他們希望將訊息自動神奇地轉換為物件或介面或結構，或者用於程式語言的正確習慣。如果不能做到這一點，他們會希望他們嘗試通過有用的診斷輸出確定性地失敗。
對於任何指定的訊息型別，他們希望能夠生成樣本，以支援測試。
他們喜歡在事件架構中智慧處理版本控制。
從歷史上看，這很難。一個原因是我經常在事件中看到的：“EventType”欄位。通常，事件流包含許多不同型別的事物，並且它們是自我描述的，因為每個事件都包含一個欄位來說明它是什麼。因此，如果沒有基於該型別欄位的排程，您無法真正解析它才能使其對程式設計師有用。更糟糕的是：我知道幾個例子，你在頂級物件裡有一個EventType列舉，然後在更深的巢狀級別進一步輸入指定一個型別，每個EDA軟體中事件都有EventType或類似事情。
特別是，由於事件往往是JSON blob，這是一個問題，因為從歷史上看，JSON Schema 對這種構造的支援非常弱。您可以根據特定領域的進行排程解析，你可以排序，等等預先處理，降低訊息處理的複雜性和錯誤訊息。
但是，也有好訊息。顯然JSON Schema專案非常活躍，在當前的草案中（-07，因為我寫這個），有一個if-then-else 結構。
banq注: 本文亮點是比較了JSON格式的同步和非同步方式，如果希望將事件納入JSON資料格式定義，這樣搞下去，json會不會成為另外一個XML，有自己的schema，也就是XSD檔案？