从JSON移至Protobuf。这值得么？

我们有可以提供XML或JSON（WCF）的REST Web服务。我在玩实现Protobufs的想法。为什么？

优点

1. 减轻服务器负载。
2. 较小的邮件大小-较少的流量。
3. 现在切换比现在容易。

缺点

1. 需要实施
2. 很难对消息进行故障排除/嗅探以进行调试。
3. 我可以在服务器上启用GZip，而JSON将消耗尽可能多的流量

您对此有何建议和/或经验？

实施它们的商业价值是否超过成本？

如果实施，则不仅需要更改服务器，还需要更改所有客户端（尽管您可以支持两种格式，并且仅根据需要更改客户端）。这将需要时间和测试，这是直接的成本。并且不要低估真正了解协议缓冲区所花费的时间（尤其是使字段为必填或可选的原因）以及将protobuf编译器集成到构建过程中所花费的时间。

那么价值超过了吗？您是否面临“我们的带宽成本占我们收入的X％，而我们不能支持”的选择？甚至“我们需要花费20,000美元来添加服务器来支持JSON”？

除非您有紧迫的业务需求，否则您的“优点”并不是真正的优点，而只是过早的优化。

在添加protobuf之前，我会维护api和某人（因为它“更快”）。唯一更快的是RTT，因为有效负载较小，可以使用gzip JSON修复此问题。

对我来说令人讨厌的部分是维护protobuf的相关工作（与JSON相比）。我使用Java，因此我们将Jackson对象映射用于JSON。添加到响应意味着将字段添加到POJO。但是对于protobuf，我必须修改.proto文件，然后更新序列化和反序列化逻辑，该逻辑将数据移入/移出协议缓冲区并移入POJO。发行版本发生过多次，有人添加了一个字段，却忘记为协议缓冲区输入序列化或反序列化代码。

现在，客户端已经针对协议缓冲区实现了，几乎是不可能的。

您可能会由此猜测，我的建议是不要这样做。