Hacker News 中文摘要

RSS订阅

为什么我不再在API中使用JSON -- Why I stopped using JSON for my APIs

原文链接 | HN讨论 | 2025-12-02 15:12:52

文章摘要

文章作者认为JSON虽为API数据交换的主流格式，但存在更高效的替代方案如Protocol Buffers（Protobuf）。他十年来在开发服务器时都避免使用JSON，并指出Protobuf等方案更适合现代开发需求，能提供更好的序列化效率和性能。

文章总结

标题：超越JSON：为何我在API开发中转向Protocol Buffers

如果你正在开发或使用API，那么有99%的概率它使用的是JSON格式进行数据交换。JSON已成为现代网络的事实标准。然而，近十年来，无论是个人项目还是专业项目，我都不再使用JSON。

令人惊讶的是，明明存在更高效的替代方案（如Protocol Buffers/Protobuf），JSON却依然无处不在。本文将解释原因。

序列化背景

API（应用程序编程接口）是允许两个系统通信的规则集合。在网络世界中，REST API（使用HTTP协议及其方法如GET、POST等）最为普遍。客户端向服务器发送请求时，消息包含： - 头部（如Content-Type标明消息格式） - 正文（实际数据） - 响应状态

序列化是将数据结构转换为可传输字节序列的过程。JSON将数据序列化为人类可读的文本。

JSON流行的原因

  1. 可读性强：非开发者也能轻松理解。
  2. 与Web完美集成：由JavaScript推动，后端框架广泛采用。
  3. 灵活性高：可动态增删字段或修改类型。
  4. 工具丰富：任何文本编辑器均可查看，Curl即可发送请求。

Protobuf的优势

Protobuf由Google于2001年创建，2008年公开，广泛用于微服务架构中的服务间通信。其核心优势包括：

强类型与现代工具链

通过.proto文件明确定义数据结构，例如： proto message User { int32 id = 1; string name = 2; string email = 3; bool isActive = 4; } 每个字段有严格类型、数字标识和稳定名称。使用protoc工具可自动生成多语言代码（如Dart、TypeScript等），彻底避免手动验证和类型错误。

高效的二进制序列化

  • 体积更小：相同数据比JSON小约3倍（如78字节的JSON仅需23字节）。
  • 优化技术：变长整数编码、数字标签替代文本键、无空格开销。
  • 实际收益：节省带宽、提升响应速度、改善移动端体验。

实践示例：Dart服务器与客户端

  1. 服务端：使用Shelf框架返回Protobuf格式的User对象，设置Content-Type: application/protobuf。
  2. 客户端：通过http包请求数据，利用生成的Protobuf类直接解码，实现端到端类型安全。

JSON的剩余优势

Protobuf的二进制格式需依赖.proto模式才能语义化解读，而JSON可直接阅读。这要求： - 专用调试工具 - 模式版本管理 - 解码工具支持

结论

尽管常与gRPC关联，Protobuf可独立用于任何HTTP API。如果你追求更高性能、更强健性、更少错误及更优开发体验，强烈建议在下一个项目中尝试Protobuf。这一成熟工具在公共API领域尚未得到应有的关注，但其潜力值得挖掘。

（注：全文在保留核心技术细节和逻辑脉络的基础上，删减了部分代码示例和重复性说明，确保信息密度和可读性平衡。）

评论总结

评论内容总结

1. 对文章质量的质疑

  • 观点：文章内容混乱，可能由AI生成，影响可信度。
  • 引用：
    • "Is it just me or is this article insanely confusing?"（评论1）
    • "I can't help but distrust this writing due to how much it sounds like an LLM."（评论1）

2. Protobuf的局限性

  • 观点：Protobuf虽然高效，但缺乏JSON的灵活性和广泛适用性。
  • 引用：
    • "Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives."（评论2）
    • "Technically, it sounds really good but the actual act of managing it is hell."（评论3）

3. 替代方案的建议

  • 观点：CBOR等替代方案在灵活性和效率上更优。
  • 引用：
    • "A much stronger argument could be made for CBOR as a replacement for JSON."（评论2）
    • "CBOR is a pretty good middle ground."（评论19）

4. 对Protobuf的批评

  • 观点：Protobuf并非万能，分布式系统中的版本问题仍存在。
  • 引用：
    • "Protobuf isn't a silver bullet that can solve all problems."（评论5）
    • "Protobuf clients need to be written defensively, just like JSON API clients."（评论24）

5. JSON的优势

  • 观点：JSON在可读性、简单性和广泛支持上优于Protobuf。
  • 引用：
    • "JSON is ubiquitous, human readable, and simple."（评论7）
    • "The zero cost of starting with JSON is too compelling."（评论11）

6. 对文章标题的批评

  • 观点：文章标题过于主观，未客观比较JSON和Protobuf。
  • 引用：
    • "No it's not, you just like it better, which is FINE, just own it."（评论12）
    • "Why I stopped caring about 'Why I stopped [insert something widely used here]' click bait articles."（评论26）

7. Protobuf的实际应用问题

  • 观点：Protobuf在浏览器支持和工具链上存在问题。
  • 引用：
    • "Protos don't work out of the box in any browsers."（评论15）
    • "The setup wasn't hard but wasn't trivial either."（评论13）

8. 其他替代技术

  • 观点：ASN.1等老技术已实现Protobuf的功能。
  • 引用：
    • "ASN.1, a protocol from 1984, already did what Protobuf does."（评论9）
    • "DCE/RPC worked in 1993, and still does today."（评论21）

9. 对性能优化的反思

  • 观点：性能优化应权衡实际需求，避免过度复杂化。
  • 引用：
    • "If JSON's size or performance is causing you to go out of business, you surely have bigger problems."（评论15）
    • "The app after optimizations: 20req/sec (It waits for db query anyway)."（评论27）

10. 未来展望

  • 观点：JSON可能被更低成本的技术替代，但目前仍占主导。
  • 引用：
    • "JSON is never going away, until it gets replaced with something with even lower human communication cost."（评论11）
    • "Just wondering if the inherent deficiencies of JSON can somewhat be improved by CUE lang."（评论20）