用於JSON REST/RPC接口的IDL

我們正在設計一個相當複雜的REST API，其中大部分I/O都是具有特定結構的JSON編碼對象。我們發現的一個挑戰是以這種方式記錄API，使客戶更容易發佈正確的輸入和處理輸出。由於輸入和輸出的數據都需要相當複雜的JSON對象，客戶端開發人員通常會引入與I/O對象結構相關的錯誤。用於JSON REST/RPC接口的IDL

與所有的JSON網絡API的是，這些天，我會希望有一個通用的解決方案，但我有一個很難找到一個。我研究了json-schema這是一個json驗證模式，但IETF草案和實現似乎都相當不成熟（儘管它們已經存在了一段時間，這不是一個好兆頭）。

Protocol Buffers和Apache Avro提供了一個稍微不同的方法，其中架構不用於驗證，但實際上需要消息的編碼/解碼。在這兩個中，Avro似乎具有相當有限的文檔和實現。 ProtoBuf似乎更好，但我不確定這是否真的適合用在瀏覽器中調用JSON API？

現在我開始懷疑，如果我從合適的角度看這個。是否有其他方法可以使我的API更強大一些？或者是對JSON REST/RPC API的正式描述，這會破壞使用JSON的目的？

編輯：這個話題6個月後，我們發現mongoose，這是非常接近我們了找誰。

來源

2012-05-27 Jeroen

如果你真的需要使用現有的解決方案，我只需要使用json-schema，這似乎很容易使用。否則，我認爲自己檢查JSON結構並不難 - 檢查每個對象是否具有您需要的屬性，並且如果您也有這樣的屬性，請遞歸執行。與XML不同，JSON的驗證非常簡單，這可能是爲什麼沒有適當的模式驗證解決方案存在。 –

下面的答覆我通過電子郵件從Douglas Crockford收到。

我不相信模式作爲輸入驗證的替代方案。有些屬性無法從語法中驗證。我認爲這是XML出錯的方式之一。

如果你的格式是太複雜了，那麼我想看看簡化他們。

來源

2012-06-01 02:55:40 Jeroen

我想說你最後一個問題的答案是肯定的。如果您需要一種方法來約束和記錄JSON「模式」，爲什麼不首先使用XML？解析並不困難，並且能夠爲它強制執行一個模式是一個很大的優點。

來源

2012-05-30 06:58:50 vektor

XML是在許多方面RESTful服務更好。它具有本地鏈接（<link href=，對於所有那些HATEOAS粉絲），本地語言支持（lang="en"）和一個偉大的生態系統。

這對未來的校對和將來的API重構也更好。這個轉換：

<profile> 
    <username>alganet</username> 
</profile>

爲了支持更多的用戶名：

<profile> 
    <username>alganet</username> 
    <username>alexandre</username> 
</profile>

是更簡單的做而不會破壞現有的客戶使用XML。 JSON在這方面很難。

如果你真的需要JSON，JSON-Schema是要走的路。這是不成熟的，但我對這種情況並不瞭解。也許您的消費者可以在XML和JSON之間進行選擇，以便他們可以使用內容協商在小型有效內容（JSON）或RESTful糖果（XML）之間進行選擇。

來源

2012-06-01 03:08:07 alganet

這樣的系統存在，我是其中之一的作者。它被稱爲Piqi-RPC，它通過HTTP對基於IDL的RPC樣式API進行輸入和輸出參數驗證。

它支持JSON，XML和Google Protocol Buffers作爲HTTP POST請求的輸入和輸出的數據表示格式。客戶可以選擇使用這三種格式中的任何一種，並使用標準的Accept和Content-Type HTTP標題指定他們的選擇。

所以，從理論上講，您正在尋找正確的方向。但是，目前，Piqi-RPC僅支持在Erlang中編寫服務器，如果您使用不同的堆棧，對您而言不會很有用。我聽說Apache Thrift也支持通過HTTP傳輸的JSON，但我沒有檢查。我所知道的另一種類似的系統（也稱爲Erlang）被稱爲UBF。我聽說過Java的庫，它可以根據Protocol Buffers規範解析和驗證JSON（例如http://code.google.com/p/protostuff/）。

這個想法本身並不新鮮，但實際上並沒有太多的系統接近它。這是一個挑戰性的問題。

歷史上，用於接口定義和二進制數據序列的IDL和沒有那麼多，用於驗證其後來出現動態數據交換格式（例如XML和JSON）。 Sun-RPC IDL和CORBA IDL屬於第一類。 WSDL將是覆蓋這兩個領域的少數幾個例子之一，但它是一種可怕的技術，對於大多數現代系統來說這是一個糟糕的選擇。此外，還有許多模式語言（也稱爲DDL--數據定義語言），其中大多數是高度專業化的，並且僅以一種表示格式工作，例如， XML或JSON模式。很少有那些穩定的實施。

的Piqi project和Piqi-RPC，這是基於它，是圍繞打造幾個非常簡單的實現：

DLL不必被明確地依賴於任何特定的數據表示格式或周圍建它。相反，這樣的語言可以是相當通用的並且涵蓋了廣泛的實際使用情況（例如，跨語言數據序列化和數據驗證）和數據格式（例如JSON，XML，協議緩衝區）。
IDL用於RPC樣式的通信可以被實現爲在通用DDL上的薄，大多句法層。
這種IDL和接口規範可以是傳輸不可知的。

說到HTTP上的REST風格的API與HTTP上的RPC風格的API相比。

隨着RPC風格的API，服務開發者或自動化系統必須確認三兩件事：函數名（根據一些服務命名方案），輸入，如果你選擇的話，輸出。

在REST風格的API的情況下，人們讓自己在沒有很好的理由麻煩。現在，他們有一個很多東西來驗證：任意複雜的URL語法，包括網址片段編碼（適用於所有HTTP方法）動態參數和URL查詢字符串（僅適用於HTTP GET方法），HTTP方法對應（它是否應該是GET，POST，PUT，DELETE等。），一些參數到達時的HTTP主體（有時它們會爲JSON和XML所表示的參數手動執行兩次），自定義HTTP標頭以及單獨的服務文檔。想象一下IDL支持所有這些！

來源

2012-06-04 06:40:44 alavrik

用於JSON REST/RPC接口的IDL

回答

相關問題