使用ProtocolBuffers代替JSON的五个原因

在Ruby和Rails开发者中,面向服务(Service-Oriented)架构有一个当之无愧的名声,它是一个缓解程序规模恶性增长的一个强有力的途径,可在大量应用程序中提取关注点。这些新生小巧的服务通常继续使用Rails或Sinatra,并使用JSON在HTTP上通信。尽管JSON作为一个数据相互交换格式,有很多优点:人类可读、可理解,并通常表现出色。

浏览器和JS并不直接处理数据–尤其是遇到内部服务时。我的观点是,结构化格式,例如谷歌的Protocol Buffers,是一个比JSON在编码方面更好的选择。如果你从来没有使用过Protocol Buffers,你可以参看 这里。不要担心,在说明为什么要选择Protocol Buffers而不是JSON之前,本文会简介如何使用在Ruby上使用它 。

Protocol Buffers

首先,什么是Protocol Buffers?文档中说:

“Protocol Buffers是一种以有效并可扩展的格式编码结构化数据的方式。”

Google开发了Protocol Buffers使用于内部的服务。 它是一种二进制格式允许你使用规范的语言定义一个模式,例如:

 message Person {
  required int32 id = 1;
  required string name = 2;
  optional string email = 3;
}

你能在命名空间中封装他们或者用上面的方式在顶层声明他们。

优点

原因一 模式本身

我们小心谨慎地在我们的数据库里面编写数据模型,维护各个层次的代码,保持这些数据模型处于控制之中。但当我们想要发送数据连接到另一个服务的时候,我们往往依靠的是在边界上与我们的系统之间不一致的代码,我们的系统不能强制结构化我们的数据组件。在proto格式中,它足以帮助并保证应用程序之间的状态不会丢失。

原因二 后向兼容

已经部署各种JSON的服务器已经遭受各种与发展模式以及向后兼容的相关问题,而被编号的字段在proto的定义中排除了所需的版本检查。

原因三 更少代码

一个类可以通过Protocol Buffers产生(你一般就不会再去触碰它),它能提供大量相似的方法,还避免了大量头痛的事情。你可以把更多的空间留给你所关注的业务逻辑。

原因四 验证与扩展

required,optional 和 repeated关键字在Protocol Buffers中的定义是非常强大的。它们允许你去编码,在模式级别,形象化你的数据结构和去实现类怎样工作的细节。

##原因五 语言互操作性

因为Protocol Buffers已经被多种语言实现,在你的架构中多语言混合的应用程序之间的互操作性变得更简单。

什么时候更适合使用JSON?

  1. 你需要或者想让数据对人是可读的
  2. 来自于服务的数据是直接发送到web浏览器
  3. 你的服务端应用程序是用javaScript编写的
  4. 你不准备把数据模型绑定到模式上
  5. 你没有带宽添加另外一个工具到你的军火库
  6. 运行不同类型的网络服务的运营负担过大

英文原文