Data Formats for Communication

Clients and servers communicate by exchanging data using a request-response model. An essential aspect of this communication is the data format(s) used for exchanging information. This significant factor sets the difference between an effective and an inept API. One aspect of frontend System Design is the choice of a data format that both the client and server can understand conveniently and enhance the system’s performance.

The choice of data format is only the first step to a standardized information flow between the sending and receiving parties. Rapidly changing industry demands make it inevitable to change or update the chosen data formats over time. Making changes to the server side may also require updating the client side. It’s relatively easy to reflect changes for the browser-based client interfaces where a simple refresh may be enough to push the client to a newer version. But for the clients that use installed software—such as mobile applications—to interact with the service, we often use rolling software updates, where the more recent version is gradually installed on the client-side. Therefore, data representation and data versioning are important concerns during design. The discussed scenario is depicted in the image below:

Choosing a data format

The best data format for a design problem is a tradeoff between different factors and the features a specific format provides. In general, a format is considered to be a good choice if it supports the following:

• Human-readable: Easy to read and debug by developers

• Low latency: Fast to transmit over the wire

• Standardized: Follows a well-defined pattern in the industry

• Machine friendly: Needs less time to be processed by machines

• Interoperable: Easy to serialize and deserialize data into different formats

• Flexible: Easy to introduce and manage changes over time

Choosing an inappropriate data format

Selecting an inappropriate data format for communication between the frontend and backend can lead to increased computational overhead, unnecessary conversions, and potential data inconsistencies. When the frontend expects data in a specific format (Format X) but the backend provides it in a different format (Format Y), an additional conversion layer must process the data before it can be used. Over time, as either the frontend or backend evolves, outdated conversion logic may lead to data corruption, inaccuracies, and unexpected application behavior.

For instance, a video streaming platform that expects JSON metadata for video details but receives XML responses from the backend will require continuous conversion before rendering. If the API format changes without proper handling, essential fields like video duration, captions, or resolutions may become unreadable or incorrectly mapped, degrading the ...