為什么 JSON API 還沒有發(fā)布版？

一旦 JSON API 發(fā)布穩(wěn)定版，它將保持向后兼容，它將遵守永不刪除，只是添加的開發(fā)策略。 #46

為什么不使用 HAL 規(guī)范？

有幾個原因:

• HAL 遞歸嵌套子文檔，而 JSON API 在頂層采用扁平化對象結(jié)構(gòu)。意味著不同的對象引用相同的 “people”（例如，posts和comments的author）時，這種規(guī)范能夠保證每個person document僅存在一個有效實例。

• 相似的，JSON API 使用 IDs 做鏈接，使從復(fù)合響應(yīng)中緩存文檔成為可能，僅當(dāng)本地不存在對應(yīng)文檔，才會發(fā)出后續(xù)請求。如果幸運，甚至可以完全無需HTTP請求。

• HAL 是序列化格式，但完全未定義文檔更新操作。JSON API 則仔細考慮如何更新已存在文檔（依賴 PATCH 和 JSON PATCH），以及更新操作與GET請求返回復(fù)合文檔交互方式。同時定義如何創(chuàng)建，刪除文檔，以及更新操作的 200,204 響應(yīng)。

簡單來說，JSON API 嘗試格式化相似的，特殊的client-server通訊接口，使用 JSON 作為數(shù)據(jù)交換格式。專注于使用成熟的客戶端來調(diào)用相關(guān)API，客戶端能夠緩存已經(jīng)獲取到的文檔，避免再次請求已緩存信息。

JSON API 從大量實際項目所使用的庫中抽象而出。同時定義請求/響應(yīng)（HAL 未定義），以及對應(yīng)數(shù)據(jù)交互格式。

如何獲取資源可能的行為？

你應(yīng)該使用 OPTIONS HTTP 方法來獲取當(dāng)前特定資源的行為。OPTIONS 請求返回方法的語義遵循 JSON API 標(biāo)準(zhǔn)。

舉例來說，如果"GET,POST"是 URL OPTIONS 請求的響應(yīng)，那么就可以獲取該資源信息，以及創(chuàng)建新資源。

如果你想知道特定資源屬性作用，你不得不使用應(yīng)用級別的描述來定義屬性的含義與功能，并使用錯誤響應(yīng)通知用戶。這個特性依舊在討論中，尚未加入最終標(biāo)準(zhǔn)。discussion.

有沒有 JSON 規(guī)范來定義 JSON API?

當(dāng)然，你可以在http://jsonapi.org/format找到 JSON 規(guī)范定義。注意這個規(guī)范并不完美。 因為JSON文檔可能會通過規(guī)范檢查，但并不意味著是合適的 JSON API 文檔。規(guī)范只是為了常規(guī)性排錯檢查。

可以在http://json-schema.org找到更多關(guān)于JSON 規(guī)范格式的信息。

為什么資源集合作為數(shù)組返回，而不是ID索引集合？

JSON 數(shù)組是自然排序，而集合需要元數(shù)據(jù)進行成員排序。因此，默認(rèn)情況下，數(shù)組能夠?qū)崿F(xiàn)更自然的排序或者特殊方式排序。

除此之外，JSON API 允許返回不包含 IDs 的只讀資源，與IDs索引集合方式不兼容。

為什么關(guān)聯(lián)資源嵌套在復(fù)合文檔的 linked 對象中？

主要資源應(yīng)該相互獨立，因為他們的順序和數(shù)量通常比較重要。通過多種方式，分離主要資源和關(guān)聯(lián)資源是必要的，因為主要資源可能會有相同類型的關(guān)聯(lián)資源（e.g. the "parents" of a "person")。關(guān)聯(lián)資源嵌套在 linked 中能夠防止可能的沖突。