JSON Schema 的架構範疇

最近，我進行了一些對話，讓我開始思考 JSON Schema 在架構上的定位。今天我想分享一些這些想法。

什麼是 JSON Schema？

JSON Schema 是一種規範，定義了一種描述 JSON 值的方式，可用於驗證和註解該值。此機制組織成多個關鍵字，每個關鍵字都提供定義好的行為。

一組關鍵字構成一個「模式」。

此系統的輸入包括一個模式（本身可表示為 JSON 值）和一個 JSON 值（我們稱之為「實例」），模式中的規則將應用於該實例。為方便起見，本文將這些規則的應用稱為「評估」（也就是說，一個模式「評估」一個實例）。

評估的輸出是每個規則的個別錯誤和/或註解的彙總。

然而，一般而言，行為系統有些抽象，因此實際上並不實用。我們需要的是在程式碼中實現此系統。我們需要的是實作。

讓 JSON Schema 發揮作用

在我們可以讓 JSON Schema 發揮作用之前，我們需要問問它應該對誰有用。要回答這個問題，我們需要先知道 JSON Schema 最初存在的原因。

嗯，我們在前一節中談到了這一點：一個模式會評估一個實例，以確保該實例符合模式所表示的所有規則。如果實例確實符合模式中的規則，那麼我們就說它針對該模式是「有效的」。

確保我們擁有有效 JSON 資料的原因可能有很多：在反序列化為程式模型之前檢查資料、在提交之前檢查表單輸入等等。這些是應用程式的需求。

因此，應用程式是 JSON Schema 的使用者。

那麼註解呢？好吧，註解是專門為應用程式設計的，以便它們可以提供額外的行為。所以，是的，應用程式仍然是這裡的使用者。

但是，如果沒有將規範實現為程式碼，應用程式就無法使用規範。這就是實作的用武之地。

JSON Schema 的實作是規範的體現，應用程式可以直接使用它。

一個細微之處

我最近看到很多，並且我認為這是我討論中出現的一些混淆的根源，那就是應用程式可能僅僅是實作周圍的可執行包裝器。這往往會讓人覺得應用程式本身就是實作，在這種情況下，應用程式將受規範的要求約束。但我不這麼認為。即使在這些情況下，應用程式和實作之間仍然存在區別，即使這種區別在實務中非常模糊。

注意 重要的是要認識到這種區別實際上是模糊的。這目前是一個公開討論的問題，並且在此領域中尚未正式定義任何內容。

應用程式往往有三個基本組件：介面（UX 或 API）、一些業務邏輯和資料持久性。所有應用程式都有介面。但是，業務邏輯和資料持久性元件是可選的，您可以選擇其中之一或兩者都有。（只有 UX 的應用程式通常不是很有用。）

應用程式可能只提供資料持久性的介面（例如，Postgres Web 服務），這意味著不需要任何業務邏輯。相反地，另一個應用程式可能會提供運算服務（例如，影像處理），而不需要持久化資料。

對於我最近進行的對話，第二種情況似乎是這樣：創建了一個僅針對模式評估實例的應用程式。但是，這並不意味著應用程式和實作是同一件事。

在這些應用程式中，實作（對於這些應用程式而言，是業務邏輯）仍然是與介面分開的元件。重要的是要認識到，JSON Schema 作為規範只能涵蓋實作部分。

為何這些都很重要

這一切都回歸到我在開頭部分談到的：JSON Schema 需要定義輸入和輸出。這包括實作和應用程式可以相互通信的最小 API。

當實作和應用程式之間的界限模糊時，很自然地會認為規範正在對應用程式如何與其使用者進行通信施加要求。但事實並非如此。

JSON Schema 無法知道應用程式使用者的需求，因此規範嘗試定義應用程式必須遵守的輸入和輸出要求是不切實際的。

不同應用程式的使用者有不同的需求。即使您考慮到兩個基本上僅為實作提供 UX 的應用程式（例如 Web 應用程式和 CLI），它們使用者的 UX 需求也大不相同，儘管這兩個應用程式基本上做著相同的事情。

規範的範疇

根據上面討論的所有內容，規範的輸入和輸出要求僅適用於應用程式和 JSON Schema 實作之間存在清晰的通信接縫時。

該規範認識到程式語言和框架可能不會處理文字 JSON，而是會使用該語言的限制內定義的資料模型。因此，它以抽象的 JSON 資料和 JSON Schema 模型來定義輸入和輸出，以便實作可以自由使用它們所擁有的資源。

具體來說，這些要求僅適用於作為 JSON Schema 規範的一般用途表示形式提供的獨立實作，供未知的各方使用。

已整合實作的應用程式或具有專門合約的應用程式/實作配對無需遵守這些要求，因為這些安排超出了規範的範圍。

封面照片由我拍攝 😁