2009-10-07 35 views
4

你有沒有看到有一個很好的理由來創建一個自定義的二進制休息協議,而不是使用基本的http rest實現?自定義休息協議是基於二進制的而不是基於Http的文本是一件好事嗎?

我目前致力於.Net中面向服務的體系結構框架,負責託管和使用服務。我不希望基於Remoting或WCF等現有框架,因爲我希望完全靈活性和控制來執行自定義優化。

所以我在這裏試圖找到處理這個SOA框架的最佳協議。我喜歡REST和URI的請求/響應無狀態連接性質來定義資源,但我不喜歡HTTP的基於文本的本質。

這裏是我的不喜歡HTTP參數,糾正我,如果我錯了:

  • 首先一個證據,解析文本比分析二進制效率較低。 我更喜歡一個包含內容長度和二進制內容的固​​定長度的二進制頭文件。

  • 其次,http請求沒有序列號的概念,因此將響應與其請求關聯的唯一方法是用於發送請求和接收響應的套接字連接。 這意味着一次只能有一個待處理的請求用於指定的套接字,因此如果服務使用者想要將多個請求並行發送到服務,則需要向服務器打開多個套接字。 自定義休息協議可以爲請求定義序列號,因此請求和響應將與序列號而不是套接字關聯,並且可能在同一個套接字上並行發送多個請求。 我認爲沒有辦法通過HTTP來實現這一點,它可以使用基於自定義文本的協議來完成,但爲什麼不以二進制爲基礎來獲得性能。

要補充一點背景,我的SOA框架並不需要從非淨消費者的訪問,所以我不知道使用.net二進制格式或其他自定義二進制格式化限制。

那麼我想要一個自定義的二進制休息協議?如果你認爲我錯了,請告訴我你的論點。

謝謝。

回答

3

數據包的數據可以是任何你喜歡的;無論是XML,Plaintext,JSON還是二進制格式。我看不出有任何理由強迫你自己選擇其中的一種(使用最合適的)。

儘管在說'二進制格式'時,大多數人聽到固定格式的字段長度和其他非常煩人的東西。一般來說,如果你不是從數據傳輸的角度來看絕望的話,我沒有理由這麼做[儘管你可以做一個.net對象的二進制序列化,以便它們可以被重新實例化(或者看看'協議緩衝區'的.net的.net]]。

摘要:似乎對我好。無論漂浮你的船。

+0

感謝您的回答,我會考慮使用靈活的長度標題,這樣可以更容易地構建協議的擴展。 – 2009-10-07 04:01:09

7

REST是構建Web服務的體系結構風格。 Roy Fielding基於他在設計HTTP方面的經驗闡述了它,但它超越了HTTP。例如,您可以通過普通的電子郵件交換來部署RESTful服務。

你的資源的REST表示可以是你喜歡的任何東西,但Roy真的強調人們應該嘗試使用非常精心設計的標準表示。二進制沒有問題。實際上,像JPEG和PNG這樣的圖像表示是二進制的。 Google的Protocol Buffers爲您提供了創建結構化數據的緊湊二進制表示的方法。

所以簡短的回答是,您當然可以使用RESTful,並使用二進制表示和本地二進制替代HTTP。不過,我實際上非常強烈地建議你使用HTTP來提高效率。如果您使用自己的協議,那麼您會失去服務器和客戶端之間精彩的HTTP緩存基礎設施提供的所有槓桿作用。完整的客戶端負載落在您的服務器上,而不是分散在中間緩存上。

2010年10月4日:在我們基於HTTP的REST API中,除了XML,JSON和XHTML之外,我們現在還支持Java序列化對象和Kryo二進制表示。 Kryo序列化庫的性能明顯優於其他版本,無需任何特殊協議。另一種減少帶寬的方法是使用HTTP compression以及文本表示。

+0

感謝您的厚愛。由我的SOA框架託管的服務主要負責執行操作,而不是返回靜態內容。所以他們不會利用緩存基礎設施。我想我會堅持使用二進制來獲得性能。 – 2009-10-07 03:57:55

1

你有沒有看過一個很好的理由來創建一個自定義的二進制休息協議,而不是使用基本的http rest實現?

我不確定我是否理解你的條款。 REST表示可以完全是二進制的,並且仍然通過純HTTP進行傳輸。沒有必要發明一個新的協議來傳輸二進制數據。只需將您的需求減少到記錄良好的媒體類型(您可以自由發明)。

關於二進制資源表示,Fielding himself認爲二進制不僅可以接受,但可能在某些情況下需要。

無論你是否直接使用二進制,Base64與文本混合,或純文本,don't forget the hypertext constraint如果你打算調用你做的「REST」。

那麼我想要一個自定義的二進制休息協議?

如果你的意思是你想創建一個自定義的,二進制只,超文本驅動的媒體類型 - 這是完全合理的。

如果你正在談論發明HTTP的一些自定義擴展,除非絕對必要(並且你描述的內容對我來說聽起來並不像上升到那個水平),否則我會避免這種擴展。

1

我想總的靈活性和控制

基於在此聲明,那麼我建議兩個選擇。直連TCP/IP套接字或WCF。這些選項可爲您提供最大的靈活性。如果您希望與傳輸無關,並且您希望從應用程序協議的乾淨狀態入手,那麼WCF是一個很好的解決方案。

REST強加了一組約束,它們限制了分佈式應用程序的行爲方式以獲得某些有益特性。如果你看到你的服務端點是調用操作的方法,那麼我建議REST不會很好地滿足你的需求。

不知何故,我不認爲你發送二進制或文本有效載荷應該是你最關心的問題。

相關問題