| 網際網路工程任務組 | A. Wright，編輯 |
| 網際網路草案 | |
| 預期狀態：資訊性 | H. Andrews，編輯 |
| 截止日期：2017 年 10 月 23 日 | Cloudflare, Inc. |
| G. Luff | |
| 2017 年 4 月 21 日 |
JSON 超級綱要：用於 JSON 超媒體註解的詞彙
draft-wright-json-schema-hyperschema-01
JSON Schema 是一種基於 JSON 的格式，用於定義 JSON 資料的結構。本文件指定了 JSON Schema 的超連結和超媒體相關關鍵字，用於使用超連結註解 JSON 文件，並提供透過 HTTP 等超媒體環境處理和操作遠端 JSON 資源的說明。
本草案的問題列表可在 <https://github.com/json-schema-org/json-schema-spec/issues> 找到。
如需更多資訊，請參閱 <https://json-schema.dev.org.tw/>。
若要提供回饋，請使用此問題追蹤器、首頁上列出的溝通方法，或電子郵件給文件編輯。
本網際網路草案完全符合 BCP 78 和 BCP 79 的規定。
網際網路草案是網際網路工程任務組 (IETF) 的工作文件。請注意，其他群組也可能將工作文件作為網際網路草案發布。目前網際網路草案的列表位於 http://datatracker.ietf.org/drafts/current/。
網際網路草案是有效期最長六個月的草案文件，並且可能會隨時被其他文件更新、取代或廢棄。將網際網路草案作為參考資料或將其引用為「進行中的工作」是不恰當的。
本網際網路草案將於 2017 年 10 月 23 日到期。
版權所有 (c) 2017 IETF Trust 及被識別為文件作者的人士。保留所有權利。
本文件受 BCP 78 和 IETF Trust 的關於 IETF 文件的法律規定（http://trustee.ietf.org/license-info）的約束，該規定在本文件發布之日生效。請仔細審閱這些文件，因為它們描述了您在本文件方面的權利和限制。從本文件中提取的程式碼元件必須包含 Trust 法律規定的第 4.e 節中描述的簡化 BSD 授權文字，並且在沒有簡化 BSD 授權中描述的擔保的情況下提供。
JSON Schema 是一種基於 JSON 的格式，用於定義 JSON 資料的結構。本文件指定了 JSON Schema 的超連結和超媒體相關關鍵字。
術語 JSON 超級綱要用於指使用這些關鍵字的 JSON Schema。
本規範將使用 JSON Schema 核心規範 [json-schema] 定義的術語。建議讀者擁有一份本規範的副本。
本文件中使用的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」應按照 RFC 2119 [RFC2119] 中描述的方式進行解釋。
術語「綱要」和「實例」應按照 JSON Schema 核心規範 [json-schema] 中定義的方式進行解釋。
本文件說明如何使用 JSON Schema 在實例資料上定義超連結。它還定義了如何提供將 JSON 資料解釋為豐富多媒體文件所需的其他資訊。
與所有 JSON Schema 關鍵字一樣，「綱要關鍵字」部分中描述的所有關鍵字都是選用的。最小有效的 JSON 超級綱要是空白物件。
以下是一個定義超連結的 JSON Schema 範例，並為「imgData」屬性提供多媒體解釋
{
"title": "Written Article",
"type": "object",
"properties": {
"id": {
"title": "Article Identifier",
"type": "number",
"readOnly": true
},
"title": {
"title": "Article Title",
"type": "string"
},
"authorId": {
"type": "integer"
},
"imgData": {
"title": "Article Illustration (thumbnail)",
"type": "string",
"media": {
"binaryEncoding": "base64",
"type": "image/png"
}
}
},
"required" : ["id", "title", "authorId"],
"links": [
{
"rel": "self",
"href": "/article{?id}"
},
{
"rel": "author",
"href": "/user?id={authorId}"
}
]
}
此範例綱要定義了實例的屬性。對於「imgData」屬性，它指定應將其進行 base64 解碼，並將產生的二進位資料視為 PNG 影像。它還定義了實例的連結關係，其中 URI 結合了實例中的值。[CREF1]「id」通常不應是必要關鍵字，因為新實例在伺服器指派之前，將會有一個未知的「id」屬性。但是，此屬性在連結中使用，如果沒有它，多個不同的實例將被賦予相同的 rel=self URI！
以上述綱要描述的 JSON 實例範例可能是
{
"id": 15,
"title": "Example data",
"authorId": 105,
"imgData": "iVBORw...kJggg=="
}
base-64 資料為方便閱讀而縮寫。
如果實例未能通過其內或包含超級綱要的驗證關鍵字進行驗證，則不得將超級綱要應用於該實例。在「anyOf」或「oneOf」中未通過驗證的分支，或在與實例無關的「dependencies」子綱要中的超級綱要關鍵字必須忽略。
在「not」中包含的子綱要中的超級綱要關鍵字，無論深度如何，包括任意數量的中間「not」子綱要，都必須忽略。
如果「contains」關鍵字的子綱要包含超級綱要關鍵字，則必須將其應用於所有通過綱要驗證的陣列元素。雖然找到單個通過驗證的元素足以確定驗證結果，但當存在超級綱要關鍵字時，必須針對所有陣列元素評估子綱要。
JSON Schema 驗證的目前 URI 是 <https://json-schema.dev.org.tw/draft-06/hyper-schema#>。
如果存在，則此關鍵字會根據整個實例所在的目前 URI 基礎進行解析，並設定實例中 URI 參考的新 URI 基礎。因此，無論在哪個順序找到它，它都是第一個被解析的 URI 參考。
URI 是使用與連結描述物件的 「href」 [href] 屬性描述的相同程序，從提供的 URI 範本計算得出。
以下是使用「base」的 JSON 綱要範例
{
"base": "/object/{id}",
"links": [
{
"rel": "self",
"href": ""
},
{
"rel": "next",
"href": "{nextId}"
}
]
}
以下是使用此綱要產生 rel="self" 和 rel="next" 連結的 JSON 實例範例
{
"id": 41,
"nextId": 42
}
如果文件 URI 是 <http://example.com/?id=41>，則新的 URI 基礎將變為 <http://example.com/object/41>
將兩個連結描述物件解析為此 URI 基礎會產生兩個與以下絕對形式 HTTP 連結標頭完全相同的連結
綱要的「links」屬性用於將連結描述物件與實例關聯。此屬性的值必須是陣列，且陣列中的項目必須是連結描述物件，如下所述。
以下是使用「links」關鍵字的綱要範例
{
"title": "Schema defining links",
"links": [
{
"rel": "self",
"href": "{id}"
},
{
"rel": "parent",
"href": "{parent}"
}
]
}
「media」屬性表示此實例包含以 JSON 字串編碼的非 JSON 資料。它描述了內容類型及其編碼方式。
此屬性的值必須是物件。如果描述的實例不是字串，則應忽略此屬性的值。
「media」關鍵字的值可能包含以下任何屬性
如果實例值是字串，則此屬性會定義應將字串解釋為二進位資料，並使用此屬性命名的編碼進行解碼。RFC 2045, Sec 6.1 [RFC2045] 列出了此屬性的可能值。
此屬性的值必須是由 RFC 2046 [RFC2046] 定義的媒體類型。此屬性定義了此綱要定義的實例的媒體類型。
如果未設定「binaryEncoding」屬性，但實例值是字串，則此屬性的值應指定文字文件類型，並且字元集應是 JSON 字串值解碼成的字元集（預設為 Unicode）。
以下是說明「media」用法的綱要範例
{
"type": "string",
"media": {
"binaryEncoding": "base64",
"type": "image/png"
}
}
此綱要描述的實例應為字串，並且其值應可解釋為 base64 編碼的 PNG 影像。
另一個範例
{
"type": "string",
"media": {
"type": "text/html"
}
}
此綱要描述的實例應為包含 HTML 的字串，使用 JSON 字串解碼成的任何字元集（預設為 Unicode）。
如果值為布林值 true，則此關鍵字表示實例的值僅由伺服器或擁有授權的機構管理，並且使用者代理修改此屬性值的嘗試預期會被伺服器忽略或拒絕。
例如，此屬性將用於將伺服器產生的序號標示為唯讀。
此關鍵字的值必須是布林值。預設值為 false。
連結描述物件 (LDO) 用於描述從實例到另一個資源的單個連結關係。連結描述物件必須是物件。
連結描述格式可以在沒有 JSON Schema 的情況下使用，並且可以透過參考規範性連結描述綱要作為使用連結的資料結構的綱要來宣告此格式的使用。規範性連結描述綱要的 URI 是：https://json-schema.dev.org.tw/draft-06/links（draft-06 版本）。
[CREF2]請注意，雖然目前的草案沒有提供明確指示 HTTP 方法支援的方式，但未來草案可能會加入提供非權威提示的方法（請參閱 GitHub 儲存庫中的 issue #73）。
客戶端可以使用連結來處理資料的方式有幾種
客戶端提供的資料的三種使用方式，在連結描述物件中各自以獨立的 schema 關鍵字處理。連結操作會忽略與其語意不相關的 schema。
連結描述物件不會直接指示目標資源支援的操作，例如 HTTP 方法。相反地，操作應主要從連結的關係類型 [rel] 和 URI 方案推斷。但是請注意，資源可能總是會在執行時拒絕操作，例如由於控制操作可用性的應用程式狀態。
預設情況下，"href" [href] 中的 URI 範本變數會從伺服器提供的實例資料解析。"hrefSchema" [hrefSchema] 允許連結指定一個 schema，用於從客戶端提供的資料解析範本變數。可以使用常規 JSON Schema 驗證功能來要求從使用者代理程式資料解析、禁止解析，或允許使用使用者代理程式資料，同時在沒有提供使用者代理程式資料時回退到伺服器提供的實例資料。
常見的模式是使用伺服器提供的實例資料解析範本化的路徑組件，同時接受使用者代理程式資料來建構查詢字串。這可以透過將路徑範本變數的 "hrefSchema" 子 schema 設定為 false 來實現，同時給予查詢字串範本變數在實例中沒有出現的名稱。這確保了路徑變數只能從實例解析，而查詢字串變數只能從使用者代理程式資料解析。有關此方法的範例，請參閱 "hrefSchema" 章節。
在 JSON Hyper-Schema 中，"targetSchema" [targetSchema] 提供目標資源表示的非權威描述。客戶端可以使用 "targetSchema" 來建構用於替換或修改表示的輸入。或者，如果缺少 "targetSchema" 或者客戶端更喜歡僅使用權威資訊，它可以與目標資源互動以確認或發現其表示結構。
"targetSchema" 並不打算描述連結操作的回應，除非回應語意表示它是目標資源的表示。在所有情況下，回應本身指示的 schema 都是權威的。當使用 HTTP URI 時，請參閱 6.6.1 節，以取得針對每個 HTTP 方法的具體指南。
"submissionSchema" [submissionSchema] 和 "submissionEncType" [submissionEncType] 關鍵字描述目標資源所實作的處理函數的範圍。否則，如上所述，對於與其不相關的操作，將忽略提交 schema 和編碼。
"href" 連結描述屬性的值是一個範本，用於確定相關資源的目標 URI。實例屬性的值必須根據實例的基礎 URI 解析為 URI 參考 [RFC3986]。
此屬性為必要。
[CREF3]由於其複雜性且無法解決 URI 範本的所有限制，因此已移除早期草案中存在的前置處理規則。本節在即將發布的草案中將會大幅修改，以使用全面的解決方案取代舊的前置處理。
"href" 的值將用作 URI 範本，如 RFC 6570 [RFC6570] 中所定義。但是，有一些特殊注意事項適用
URI 範本使用外部來源和實例的資料組合來填寫。當可以使用實例資料或使用者代理程式資料時，本節將簡單地稱為「資料」或「值」。當來源很重要時，將明確指定。為了允許使用任何物件屬性（包括空字串）或陣列索引，定義了以下規則
對於 URI 範本中的給定變數名稱，要使用的值按如下方式確定
如果存在 "hrefSchema" [hrefSchema] 且提供了使用者代理程式資料，則資料必須是符合 "hrefSchema" 值的有效實例。在執行上述列出的處理程序後，範本變數必須先從使用者代理程式資料實例解析。任何未解析的變數必須從資源實例資料解析。
當 URI 範本引用的任何值為 null、布林值或數字時，應先將其轉換為字串，如下所示
在某些軟體環境中，數字的原始 JSON 表示形式可能不可用（無法分辨 1.0 和 1 之間的差異），因此應使用任何合理的表示形式。Schema 和 API 作者應注意這一點，並且如果確切的表示形式很重要，則應使用其他類型（例如字串或布林值）。
有時，適當的值將不可用。例如，範本可能指定使用物件屬性，但未提供此類資料（或不存在 "hrefSchema"），且實例是陣列或字串。
如果範本所需的任何值既不存在於使用者代理程式資料中（如果相關），也不存在於 JSON 實例中，則可以從另一個來源（例如預設值）提供替代值。否則，連結定義應視為不適用於該實例。
"hrefSchema" 連結描述屬性的值必須是有效的 JSON Schema。此 schema 用於驗證使用者輸入或其他使用者代理程式資料，以填寫 "href" [href] 中的 URI 範本，如該節所述。
省略 "hrefSchema" 或將整個 schema 設定為 "false" 可防止接受任何使用者代理程式資料。
實作不應該嘗試使用 "hrefSchema" 驗證從資源實例資料解析的值。這允許使用者代理程式資料使用不同的驗證規則，例如支援用於日期時間輸入的拼寫月份，但使用標準日期時間格式進行儲存。
例如，這為 URI 範本中的每個查詢字串參數定義了一個 schema
{
"href": "/foos{?condition,count,query}",
"hrefSchema": {
"properties": {
"condition": {
"type": "boolean",
"default": true
},
"count": {
"type": "integer",
"minimum": 0,
"default": 0
},
"query": {
"type": "string"
}
}
}
}
在此範例中，「extra」的 schema 作為參考給出，以保持使用者代理程式資料驗證約束與對應屬性的實例驗證約束相同，而「id」給出一個 false schema，以防止該變數的使用者代理程式資料。
{
"definitions": {
"extra": {
"type": "string",
"maxLength": 32
}
},
"type": "object",
"properties": {
"id": {
"type": "integer",
"minimum": 1,
"readOnly": true
},
"extra": {"$ref": "#/definitions/extra"}
},
"links": [{
"rel": "self",
"href": "/things/{id}{?extra}",
"hrefSchema": {
"properties": {
"id": false,
"extra": {"$ref": "#/definitions/extra"}
}
}
}]
}
[CREF4]上面的範例透過使用新的 "hrefSchema" 關鍵字來模擬早期草案中使用 "get" 方法處理的行為。
"rel" 屬性的值表示與目標資源的關係名稱。該值必須是 在 RFC 5988 中建立的 IANA 連結關係類型註冊表 [RFC5988] 中的已註冊連結關係，或是遵循 RFC 3986 的 URI 生產 [RFC3986] 的正規化 URI。
與目標的關係被解釋為來自 schema (或子 schema) 應用於的實例，而不是可能在其中找到該實例的任何較大的文件中。
關係定義通常不是媒體類型相依的，並鼓勵使用者利用現有的已接受關係定義。
例如，如果定義了一個 hyper-schema
{
"type": "array",
"items": {
"links": [{
"rel": "item",
"href": "{id}"
}, {
"rel": "up",
"href": "{upId}"
}]
}
}
並且如果使用 JSON 表示檢索了一組實例資源
GET /Resource/
[{
"id": "thing",
"upId": "parent"
}, {
"id": "thing2",
"upId": "parent"
}]
這將表示對於集合中的第一項，其作為自身資源的 URI 將解析為「/Resource/thing」，並且第一項的「up」關係應該解析為「/Resource/parent」的資源。
請注意，這些關係值不區分大小寫，與它們在 HTML 和 HTTP Link 標頭 [RFC5988] 中的使用方式一致。
當使用「self」連結關係表示物件的完整表示形式時，如果目標 URI 不等同或不是用於請求包含帶有「self」連結的目標 URI 的資源表示形式的 URI 的子路徑，則使用者代理程式不應該將該表示形式視為目標 URI 所表示資源的權威表示形式。
例如，如果定義了一個 hyper-schema
{
"links": [{
"rel": "self",
"href": "{id}"
}]
}
並且從 somesite.com 請求了一個資源
GET /foo/
回應為（已新增換行符和空格）
Content-Type: application/json; profile="http://example.com/alpha"
[{
"id": "bar",
"name": "This representation can be safely treated
as authoritative "
}, {
"id": "/baz",
"name": "This representation should not be treated as
authoritative the user agent should make request the
resource from '/baz' to ensure it has the authoritative
representation"
}, {
"id": "http://othersite.com/something",
"name": "This representation
should also not be treated as authoritative and the
target resource representation should be retrieved
for the authoritative representation"
}]
此屬性定義連結的標題。該值必須是字串。
使用者代理程式可以在向使用者呈現連結時使用此標題。
這個屬性提供了一個預期用於描述連結目標表示方式的綱要（schema）。根據協定，這個綱要可能描述也可能不描述傳送到連結的任何特定請求的回應。這個屬性僅為建議性質。
資源的表示方式與 HTTP 請求和回應之間的關係由 RFC 7231，第 4.3.1 節 -「GET」、第 4.3.4 節「PUT」和第 3.1.4.2 節，「Content-Location」 [RFC7231] 決定。特別地，「targetSchema」建議客戶端可以預期 HTTP GET 的回應，或是任何「Content-Location」標頭等於請求 URI 的回應，以及客戶端在 HTTP PUT 請求中替換資源時應該傳送的內容。根據 RFC 5789 [RFC5789]，HTTP PATCH 的請求結構由「targetSchema」和請求媒體類型組合決定。
這個屬性與「mediaType」有相似的安全性考量。客戶端絕不能使用這個屬性的值來輔助解釋追蹤連結後收到的資料，因為這會使「安全」資料容易被重新詮釋。
舉例來說，假設兩位程式設計師正在使用純文字訊息佈告欄討論網路安全。以下是該對話中的一些資料，URI 為：http://forum.example.com/topics/152/comments/13
{
"topicId": 152,
"commentId": 13,
"from": {
"name": "Jane",
"id": 5
},
"to": {
"name": "Jason",
"id": 8
},
"message": "It's easy, just add some HTML like
this: <script>doSomethingEvil()</script>"
}
為了方便閱讀，訊息字串被分為兩行。
{
"rel": "evil-attack",
"href": "http://forum.example.com/topics/152/comments/13",
"targetSchema": {
"properties": {
"message": {
"description": "Re-interpret `message` as HTML",
"media": {
"type": "text/html"
}
}
}
}
}
然後，第三方可能會在另一個位置提供以下連結描述物件：
如果客戶端在解釋上述資料時使用了這個「targetSchema」值，那麼它可能會將「message」的內容顯示為 HTML。此時，嵌入在訊息中的 JavaScript 可能會被執行（在「forum.example.com」網域的上下文中）。
這個屬性的值僅為建議性質，表示在提取此資源時預期返回的媒體類型 RFC 2046 [RFC2046]。這個屬性值可以使用與 RFC 7231，第 5.3.2 節 - HTTP 「Accept」標頭 [RFC7231] 中定義的相同模式，作為媒體範圍。
這個屬性類似於 HTML 中 <a> 元素的「type」屬性（建議的內容類型），或是 HTTP Link 標頭 [RFC5988] 中的「type」參數。使用者代理程式可以利用此資訊在追蹤連結之前告知使用者他們呈現的介面，但是此資訊絕不能用於解釋產生的資料。在決定如何解釋透過追蹤此連結獲得的資料時，使用者代理程式的行為必須相同，無論這個屬性的值為何。
如果指定了這個屬性的值，並且連結的目標是使用任何支援 HTTP/1.1「Accept」標頭的協定取得的 RFC 7231，第 5.3.2 節 [RFC7231]，則使用者代理程式可以使用這個屬性的值來輔助組裝向伺服器發出請求時使用的標頭。
如果未指定這個屬性的值，則該值應視為「application/json」。
例如，如果定義了一個綱要：
{
"links": [{
"rel": "self",
"href": "/{id}/json"
}, {
"rel": "alternate",
"href": "/{id}/html",
"mediaType": "text/html"
}, {
"rel": "alternate",
"href": "/{id}/rss",
"mediaType": "application/rss+xml"
}, {
"rel": "icon",
"href": "{id}/icon",
"mediaType": "image/*"
}]
}
由此綱要描述的一個合適的實例將定義四個連結。 「rel」值為「self」的連結將具有預期的 MIME 類型「application/json」（預設值）。「rel」值為「alternate」的兩個連結指定了目前項目的 HTML 和 RSS 版本的位置。「rel」值為「icon」的連結連結到一個圖像，但未指定確切的格式。
從上述範例顯示項目的視覺使用者代理程式可能會顯示一個代表 RSS 訂閱的按鈕，按下時會將目標 URI（計算出的「href」值）傳遞給更適合顯示它的視圖，例如新聞摘要標籤。
請注意，以上述方式呈現連結，或將 URI 傳遞給新聞摘要視圖並不構成資料的解釋，而是連結的解釋。資料本身的解釋由新聞摘要執行，該摘要應拒絕任何不會被解釋為新聞摘要的資料，即使該資料顯示在主要視圖中。
連結定義中的「mediaType」屬性定義了連結目標的預期格式。但是，這僅為建議性質，絕不能被視為權威性的。
在選擇如何解釋資料時，伺服器提供的類型資訊（或從檔名推斷，或任何其他常用方法）必須是唯一的考量，並且絕不能使用連結的「mediaType」屬性。使用者代理程式可以利用此資訊來決定它們如何呈現連結或將其顯示在哪裡（例如，懸停文字、在新標籤中開啟）。如果使用者代理程式決定將連結傳遞給外部程式，它們應該首先驗證資料的類型通常會傳遞給該外部程式。
這是為了防止重新詮釋「安全」資料，類似於「targetSchema」的預防措施。
如果存在，這個屬性指示客戶端應該用於 「submissionSchema」 [submissionSchema] 所描述的請求酬載的媒體類型格式。
省略這個關鍵字的行為與值為 application/json 相同。
請注意，「submissionEncType」和「submissionSchema」不限於 HTTP URI。
例如，此連結表示，如果您想向上下文資源的作者發送電子郵件，您的客戶端需要請求純文字和 HTML 表示方式。
{
"links": [{
"submissionEncType": "multipart/alternative; boundary=ab12",
"rel": "author",
"href": "mailto:[email protected]{?subject}",
"hrefSchema": {
"type": "object",
"properties": {
"subject": { "type": "string" }
},
"required": ["subject"]
},
"submissionSchema": {
"type": "array",
"items": [
{
"type": "string",
"media": { "type": "text/plain; charset=utf8" }
},
{
"type": "string",
"media": { "type": "text/html" }
}
],
"minItems": 2
}
}]
}
這個屬性包含一個綱要，該綱要定義了根據「submissionEncType」屬性編碼並發送到目標資源進行處理的文件的可接受結構。這可以視為描述目標資源實現的處理函式的網域。
這與 「targetSchema」 [targetSchema] 屬性是不同的概念，後者描述目標資訊資源（包括在 PUT 請求中替換資源的內容），而「submissionSchema」描述使用者提交的、要由資源評估的請求資料。「submissionSchema」旨在用於具有未根據目標表示方式定義的酬載的請求。
省略「submissionSchema」或將整個綱要設定為「false」會阻止接受任何使用者代理程式資料。
| [RFC2045] | Freed, N. 和 N. Borenstein, 「多用途網際網路郵件擴充協定（MIME）第一部分：網際網路訊息主體格式」，RFC 2045，DOI 10.17487/RFC2045，1996 年 11 月。 |
| [RFC2119] | Bradner, S., 「在 RFC 中用來表示需求等級的關鍵字」，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [RFC3986] | Berners-Lee, T., Fielding, R. 和 L. Masinter, 「統一資源識別符（URI）：通用語法」，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月。 |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. 和 D. Orchard, 「URI 範本」，RFC 6570，DOI 10.17487/RFC6570，2012 年 3 月。 |
| [json-schema] | Wright, A., 「JSON 綱要：用於描述 JSON 文件的媒體類型」，網路草案 draft-wright-json-schema-00，2016 年 10 月。 |
| [RFC2046] | Freed, N. 和 N. Borenstein, 「多用途網際網路郵件擴充協定（MIME）第二部分：媒體類型」，RFC 2046，DOI 10.17487/RFC2046，1996 年 11 月。 |
| [RFC5789] | Dusseault, L. 和 J. Snell, 「HTTP 的 PATCH 方法」，RFC 5789，DOI 10.17487/RFC5789，2010 年 3 月。 |
| [RFC5988] | Nottingham, M., 「Web 連結」，RFC 5988，DOI 10.17487/RFC5988，2010 年 10 月。 |
| [RFC7231] | Fielding, R. 和 J. Reschke, 「超文字傳輸協定（HTTP/1.1）：語義和內容」，RFC 7231，DOI 10.17487/RFC7231，2014 年 6 月。 |
感謝 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 為 JSON 綱要的初始草案所做的工作。
感謝 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch、Dave Finlay 和 Denis Laxalde 為文件提交的內容和補丁。