Better Than JSON

Summary

Or why I stopped using JSON for my APIs If you develop or use an API, there’s a 99% chance it exchanges data encoded in JSON. It has become the de facto standard for the modern web. And yet, for almost ten years, whenever I develop servers—whether for personal or professional projects—I do not use JSON. And I find it surprising that JSON is so omnipresent when there are far more efficient alternatives, sometimes better suited to a truly modern development experience. Among them: Protocol Buffers, or Protobuf. In this article, I’d like to explain why. Serialization Before going any further, let’s put the topic back into context. An API (Application Programming Interface) is a set of rules that allow two systems to communicate. In the web world, REST APIs—those using the HTTP protocol and its methods (GET, POST, PUT, DELETE…)—are by far the most widespread. When a client sends a request to a server, it transmits a message containing: headers, including the well-known Content-Type, which indicates the message format (JSON, XML, Protobuf, etc.); a body (payload), which contains the data itself; a response status. Serialization is the process of turning a data structure into a sequence of bytes that can be transmitted. JSON, for example, serializes data as human-readable text. Why is JSON so common? There are many reasons for its popularity: Human-readable JSON is easy to understand, even for non-developers. A simple console.log() is often enough to inspect most data. Perfectly integrated into the web It was propelled by JavaScript, then massively adopted by backend frameworks. Flexible You can add a field, remove one, or change a type “on the fly.” Useful… sometimes too much. Tools everywhere Need to inspect JSON? Any text editor will do. Need to send a request? Curl is enough. Result: massive adoption, rich ecosystem. However, despite these advantages, another format offers me better efficiency—for both developers and end users. Protobuf: ever heard of it? There’s a st...