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 (Concise Binary Object Representation) and UBJSON (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 (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-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 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 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.
Over 10,000 developers trust Zuplo to secure, document, and monetize their APIs
Learn MoreAdvantages 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.
FAQs#
What are the key benefits of using CBOR instead of JSON for high-traffic REST APIs?#
CBOR brings notable advantages to high-traffic REST APIs when compared to JSON. Its binary format enables quicker parsing and serialization, which translates to lower CPU usage and better performance. This efficiency is especially valuable when managing heavy traffic and large volumes of requests.
Another standout feature of CBOR is its ability to support a wider variety of data types, including binary data. This capability allows it to handle more complex and varied data structures with ease. As a result, CBOR is a strong option for optimizing data transmission in environments where performance and scalability are critical.
Why is UBJSON more efficient at handling numbers compared to JSON?#
UBJSON handles numerical data more efficiently than JSON by using compact binary encoding instead of a text-based format. This method can shrink data size by about 30%, conserving both bandwidth and storage.
What sets UBJSON apart is its support for 8 different numeric types, allowing it to store numbers with higher precision while minimizing unnecessary overhead. This efficient design translates to quicker parsing and boosts performance, particularly in resource-limited environments or high-demand APIs.
What challenges might developers encounter when using UBJSON in their projects?#
Developers might encounter hurdles when working with UBJSON due to its lower adoption rate. This often translates to a smaller pool of tools and libraries, which can make tasks like integration, debugging, and overall development more time-intensive compared to widely-used formats.
Another challenge lies in UBJSON’s emphasis on simplicity and efficiency, which can sometimes lead to compatibility issues with systems already built around JSON. Bridging this gap may require additional effort to ensure systems work together smoothly. This extra work can stretch development timelines and even introduce potential security risks. To tackle these challenges, thorough planning and rigorous testing become critical.
