When building REST APIs, JSON is often the default data format due to its simplicity. However, its text-based nature can slow things down, especially for high-traffic APIs. [**CBOR**](https://cbor.io/) (Concise Binary Object Representation) and [**UBJSON**](https://ubjson.org/) (Universal Binary JSON) offer binary alternatives that reduce payload size, speed up processing, and cut resource usage while keeping JSON’s structure. Here’s the quick takeaway: - **CBOR** is standardized (RFC 8949) and widely supported across programming languages. It’s efficient for IoT, mobile apps, and APIs with high data loads. - **UBJSON** simplifies JSON processing with fewer bytes and better handling of numbers and binary data. However, it lacks CBOR’s ecosystem and tooling. **Key Benefits of Both**: - Smaller payloads = less bandwidth. - Faster serialization/deserialization = better performance. - Ideal for APIs handling millions of requests or resource-constrained environments. If performance is critical, **CBOR** is a better choice due to its strong ecosystem and tooling. **UBJSON**, while promising, may require more effort to implement effectively. ## 1\. CBOR CBOR, short for Concise Binary Object Representation, is a binary serialization format designed to enhance the efficiency of REST APIs. ### Specification and Standardization CBOR has a solid foundation in standardization. In December 2020, the [Internet Engineering Task Force](https://www.ietf.org/) (IETF) published CBOR as RFC 8949, officially establishing it as an Internet Standard (STD 94). This updated version replaces the earlier RFC 7049, introducing editorial refinements and fixing bugs while maintaining compatibility with the existing format. This ensures reliability and long-term interoperability. Additionally, CBOR's data model builds on these standards, offering greater adaptability. ### Data Model and Extensibility CBOR takes the familiar JSON data model and expands on it. It supports all common data types like strings, numbers, arrays, objects, booleans, and null values, while also adding features such as binary strings and arbitrary-precision numbers. This makes it particularly useful for tasks requiring high numerical precision, such as financial computations. Unlike JSON, CBOR avoids escaping Unicode characters, resulting in a more compact binary format. Its self-describing nature means decoders don't need a predefined schema to interpret data. Moreover, CBOR is highly extensible, thanks to [IANA](https://iana.org/)\-registered tags and simple values, allowing it to adapt to new use cases without disrupting existing decoders. ### Encoding Efficiency and Performance CBOR's design emphasizes efficiency and performance. It minimizes both code and message sizes while maintaining extensibility without requiring version negotiation. This makes it ideal for resource-constrained devices and high-throughput REST APIs. Its binary encoding reduces parsing overhead, leading to smaller payloads, lower bandwidth usage, and faster data transmission. CBOR also supports streaming processing, enabling applications to handle partial data - an essential feature for working with large datasets or real-time streams. ### Ecosystem and Tooling The strong standardization of CBOR has led to a rich ecosystem of libraries and tools across major programming languages like Python, Go, JavaScript/TypeScript, Java, and C++. These libraries handle encoding and decoding, allowing developers to focus on application logic. Many also offer streaming APIs and zero-copy parsing to meet the performance needs of demanding REST APIs. This extensive tooling further establishes CBOR as a key player in optimizing API performance. ## 2\. UBJSON ![UBJSON](https://assets.seobotai.com/zuplo.com/689941088204a37d5f93fd03/69e495d69da7ec7aab6ecdf4703194b7.jpg) UBJSON closely resembles JSON in structure but is designed to use fewer bytes and simplify processing tasks. For developers already familiar with JSON, it provides an easy path to adopt a binary format without a steep learning curve. ### Specification and Standardization While CBOR benefits from formal IETF standardization, UBJSON takes a more grassroots approach, operating as a community-driven specification. Its primary goal is to maintain complete compatibility with JSON's data structures. By directly mapping JSON value types, UBJSON makes it easy to convert between the two formats. This seamless mapping is especially useful for REST APIs that rely on JSON but want the performance boost of binary encoding. ### Data Model and Extensibility UBJSON retains JSON's core data model but introduces features that enhance binary efficiency. Unlike JSON, which uses a single number type, UBJSON supports a variety of numerical data types, such as int8, int16, int32, int64, uint8, float32, float64, and even high-precision numbers. This variety allows developers to choose the most efficient data type for each value, reducing storage requirements. Another improvement is UBJSON's ability to handle binary data natively. Instead of treating binary values as strings, it represents them as a list of integers, overcoming one of JSON's key limitations. Each data type in UBJSON is identified by specific markers, such as `Z` for null values, `T` and `F` for booleans, and markers like `i`, `I`, `l`, and `L` for different integer sizes. These features make UBJSON an attractive option for REST APIs looking to improve performance without sacrificing compatibility. ### Encoding Efficiency and Performance UBJSON achieves its efficiency through optimized handling of arrays and objects. By including metadata like container size and type, it reduces message size and allows for predictable memory allocation. This eliminates the need to parse structures with unknown lengths, speeding up the decoding process. Additionally, UBJSON's binary format sidesteps many of the inefficiencies of text-based JSON. It avoids issues like string escaping and complex number conversions, which translates to faster and more efficient decoding. ### Ecosystem and Tooling Libraries like [nlohmann/json](https://github.com/nlohmann/json) for C++ now offer full support for UBJSON, making it easy to serialize and deserialize data. Developers can convert JSON to UBJSON and back, benefiting from the format's optimized handling of arrays and objects while leveraging existing tools and workflows. ## Advantages and Disadvantages Choosing a binary format often involves weighing specific trade-offs, which can have a direct impact on API performance - a topic that comes up frequently in these discussions. **CBOR** stands out thanks to its wide-ranging support across programming languages like Python, Go, and TypeScript. This versatility is reflected in practical use cases. Take, for instance, an implementation from August 2021: jcubic used CBOR in a Scheme interpreter written in JavaScript to handle compiled code. The results were striking - a CBOR file size of 197 KB compared to 478 KB for compact JSON. That’s a 59% reduction, which significantly enhanced bootstrapping performance in web browsers. On the other hand, **UBJSON** shows potential for improving efficiency compared to text-based JSON. However, it faces challenges due to limited documentation about its ecosystem support, performance benchmarks, and compatibility with widely-used programming languages. Without detailed insights into these areas, it’s difficult to fully understand the trade-offs involved in adopting UBJSON. Further analysis is needed to clarify its strengths and limitations. ## Conclusion Both CBOR and UBJSON offer compelling alternatives to traditional JSON for optimizing REST APIs, each with its own set of strengths and trade-offs. CBOR stands out as a practical option for developers working with binary formats. Its compatibility with widely-used programming languages like Python, Go, and TypeScript makes it easier to implement. By reducing data size and speeding up transmissions, CBOR is particularly effective for mobile applications and high-traffic scenarios where performance is critical. UBJSON, while capable of improving efficiency, comes with a less developed ecosystem. This means developers may need to invest more time in testing and evaluating its fit for their use case. As noted earlier, its limited support and documentation could pose challenges, but in certain niche applications, the performance benefits might outweigh the added complexity. Choosing a binary format like CBOR or UBJSON involves balancing performance improvements with the extra effort required for debugging, caching, and managing client-side handling. To ensure a smooth transition, it's wise to test these formats on less critical endpoints before committing to a broader implementation.