在Ruby和Rails開發者中，面向服務(Service-Oriented)架構有一個當之無愧的名聲，它是一個緩解程序規模惡性增長的一個強有力的途徑，可在大量應用程序中提取關注點。這些新生小巧的服務通常繼續使用Rails或Sinatra,並使用JSON在HTTP上通信。盡管JSON作為一個數據相互交換格式，有很多優點：人類可讀、可理解，並通常表現出色。
浏覽器和JS並不直接處理數據--尤其是遇到內部服務時。我的觀點是，結構化格式，例如谷歌的Protocol Buffers，是一個比JSON在編碼方面更好的選擇。如果你從來沒有使用過Protocol Buffers，你可以參看這裡。不要擔心，在說明為什麼要選擇Protocol Buffers而不是JSON之前，本文會簡介如何使用在Ruby上使用它 。
Struts中異步傳送XML和JSON類型的數據 http://www.linuxidc.com/Linux/2013-08/88247.htm
Linux下JSON庫的編譯及代碼測試 http://www.linuxidc.com/Linux/2013-03/81607.htm
jQuery 獲取JSON數據[$.getJSON方法] http://www.linuxidc.com/Linux/2013-03/81673.htm
在 AngularJS 應用中通過 JSON 文件來設置狀態 http://www.linuxidc.com/Linux/2014-07/104083.htm
用jQuery以及JSON包將表單數據轉為JSON字符串 http://www.linuxidc.com/Linux/2013-01/77560.htm
用C語言玩JSON http://www.linuxidc.com/Linux/2014-05/101823.htm
在C語言中解析JSON配置文件 http://www.linuxidc.com/Linux/2014-05/101822.htm
首先，什麼是Protocol Buffers？文檔中說：
“Protocol Buffers是一種以有效並可擴展的格式編碼結構化數據的方式。”
Google開發了Protocol Buffers使用於內部的服務。 它是一種二進制格式允許你使用規范的語言定義一個模式，例如：
message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}
你能在命名空間中封裝他們或者用上面的方式在頂層聲明他們。這個片段定義了Person數據類型的模式，有三個字段：id, name和email。除了命名字段，你能提供一個類型決定數據怎樣編碼和在線上發送，在上面我們看到有int32類型和string類型。還提供了關鍵字進行驗證和結構化（required 和optional）。字段被編號，這有助於向後兼容，我將在以後詳細的介紹。
Protocol Buffers規范已被多種語言實現：Java,C,Go等。如果你四處找找最現代的語言都有實現的方式。Ruby也不例外，有幾個不同的Gems使用Protocol Buffers編碼和解碼數據。這就意味著，這個規范可以在不同語言實現的系統間傳遞數據。
例如，Ruby Gem安裝被稱為ruby-protoc的二進制可以和主Protocol Buffers庫組合使用（在OSX中brew install protobuf），自動的產生樁類文件用於編碼和解碼數據。正在運行的二進制proto文件產生以下的Ruby類：
#!/usr/bin/env ruby
# Generated by the protocol buffer compiler. DO NOT EDIT! require 'protocol_buffers'
# forward declarations
class Person < ::ProtocolBuffers::Message; end
class Person < ::ProtocolBuffers::Message
set_fully_qualified_name "Person"
required :int32, :id, 1
required :string, :name, 2
optional :string, :email, 3 end
正如你所見，通過支持這種模式（Protocol Buffer格式），用來編碼和解碼信息，我們就能自動得到一個類（查看代碼ProtocolBuffers::Message的基類在Gem中有更多細節的介紹）。我們已經看到了一些信息，那麼就讓我們再來仔細看看這些特征點，讓我嘗試說服你考慮Protocol Buffers——這裡有5個理由。
有一種痛苦的諷刺指向一個事實，我們小心謹慎地在我們的數據庫裡面編寫數據模型，維護各個層次的代碼，保持這些數據模型處於控制之中，當我們想要發送數據連接到另一個服務的時候，要求所有的疑慮都要被考慮到。然而，我們往往依靠的是在邊界上與我們的系統之間不一致的代碼，我們的系統不能強制結構化我們的數據組件，這是如此的重要，編碼的語義是你曾經的業務對象，在proto格式中，它足以幫助並保證應用程序之間的信號不會丟失，而界限就在你所創建並執行的業務規則。
被編號的字段在proto的定義中排除了所需的版本檢查，這是其中一個被明確表述的動機（為什麼這樣設計和實現Protocol Buffers）。如同開發者文檔中聲明的那樣，協議被設計成能在一定程度上避免出現像下面這樣的“丑陋的代碼”，下面的代碼用來檢測協議的版本:
if (version == 3) {
...
} else if (version > 4) {
if (version == 5) {
...
}
...
}
同編號字段一樣, 你必須改變編碼習慣，朝著能向老版本維護和向後兼容的方向改變。正如在文檔中的聲明那樣，曾經 Protocol Buffers 是這樣被介紹的：
“新的字段可以很容易被引入，並且不需要中間服務去檢查數據就能被解析，通過數據不必知道所有的字段。”
已經部署各種JSON的服務器已經遭受各種與發展模式以及向後兼容的相關問題。我現在深信編號字段能防止錯誤，並且能在新功能和服務的推出上做到簡化。
除了顯式的版本檢查和缺乏後續的兼容性，JSON終端在HTTP上的基礎服務通常依賴專門的手寫樣板代碼去處理Ruby對象的編碼和解碼。解析和反解析類常常包含隱藏的業務邏輯，它暴露了手動解析每個新的數據類型的缺陷，當一個類通過Protocol Buffers產生（你一般就不會再去觸碰它），它能提供大量相似的方法，還避免了大量頭痛的事情。隨著模式的發展，你將會用proto產生類（應當承認，一旦你更新他們），你可以把更多的空間留給你所關注的挑戰（保持你的應用運行和持續構建產品）。
required，optional 和 repeated關鍵字在Protocol Buffers中的定義是非常強大的。它們允許你去編碼，在模式級別，形象化你的數據結構和去實現類怎樣工作（每種編程語言處理）的細節。Ruby的protocol_buffers庫將會提升異常，例如：如果一個對象實例沒有填寫必填的字段，你試著去對這樣一個對象實例編碼，就會提升異常。通過簡單地編輯一個新的編號字段的值，你可以把一個字段從required變成optional或者反之亦然。有了這種靈活編碼的語義序列化格式，大大增強了其功能。
因為你還可以嵌入proto，定義內部的其他成員，你也可以擁有通用的Request和Response結構，它還允許其他數據結構的傳輸並確保傳輸連接上，它為服務器間通訊實現真正的靈活性和安全的數據傳輸提供了機會。類似Riak的數據庫系統使用Protocol Buffers有巨大的效果——因為有了一些啟示，我建議重新審視那些接口。
原因#5：建議的語言互操作性
因為Protocol Buffers已經被多種語言實現，在你的架構中多語言混合的應用程序之間的互操作性變得更簡單。如果你引入了一個新的服務在JAVA或者GO中，甚至和用Node或者Clojure或者Scala實現的後端通訊，你只需簡單的把proto文件交給目標語言編寫的代碼生成器，你將在這些架構之間獲得較好的安全和互操作性。平台特定數據類型的細節被目標語言處理，你將更多的關注你的問題的困難部分，而不是匹配字段和數據類型在JSON的編碼和解碼方案中。
有些時候JSON比Protocol Buffers更適合，包括如下的場景：
可能還有更多的情況。最後，總之，這是很重要的在心裡權衡和不要盲目的選擇一項技術
Protocol Buffers提供了幾種相對JSON在內部服務之間在線傳輸數據的引人注目的優勢。並沒有完全的替換JSON，特別是服務和web浏覽器直接通訊的情況，Protocol Buffers提供了真正的優勢不僅在上面概述的方法，也編解碼的速度和數據大小上有更多的優勢。
你可以從你的應用程序中提取出哪些服務？如果你今天不得不做出選擇，你會選擇JSON還是Protocol Buffers？讓我們討論討論-我們願意在下面的評論中聽到更多關於你在使用JSON和Protocol Buffers上的經驗。
