Advantages of using application/json over text/plain? [closed]

Question

Is there any performance advantage of using content type application/json sending an object serialized to json over text/plain?

I know many frameworks (like Spring) can map and serialize data based on the content type, but in general I find that this process is easy enough that it isn't a compelling reason to use application/json over text/plain for JSON objects.

Example:

xhr.setRequestHeader("Content-type","text/plain"); // or xhr.setRequestHeader("Content-type","application/json"); xhr.send(JSON.stringify({"foo": "bar"})); 

Answer 1

Let's assume that you are talking about using JSON versus a custom format (using MIME type text/plain) for passing structured data.

Performance may be broken down into different components; e.g.

• relative time taken to encode the content into the format,
• relative time taken to decode the format to give you the original content, and
• relative size of encoded content.

In theory, we can say that a hypothetical optimally designed and implemented custom format will be no slower or no less dense than JSON. (The "proof" is obvious. Choose an optimal implementation of JSON and make some minor change to the format that doesn't affect performance.)

In reality though, you have to compare performance of actual formats and actual implementations. The answer therefore that the performance really depends on how good a job you do of designing and implementing the format and its associated encoding/decoding software. Furthermore, it also depends on how you implement JSON. There are a number of server-side JSON libraries with different performance characteristics, as well as different ways of mapping data from / to "native" data structures.

This brings us to the real advantages of JSON (and XML) over custom formats.

• With JSON and XML, there are libraries available for any mainstream language you chose to use to assist in encoding and decoding content. With a custom format, you have to roll your own encoding / decoding for the client and server sides.

• With JSON and XML, there are standards that say what is well-formed that allow other people to implement encoders / decoders. With a custom format, you have to write the specification yourself if you want other people to be able to implement your format.

• JSON and XML have standard ways of dealing with issues like charset encoding and "meta" characters appearing in data. With a custom you have to understand and address these issues your self. (And if you don't, you are likely to get into difficulty down the track.)

• Ease of change. It is a relatively simple matter to evolve a JSON / XML based format. But with a custom format, you have (at least) got more work to do, and depending on your design choices, it could be very difficult.

For most application, these issues matter far more than performance. And that's why JSON or XML are widely used.

FOLLOWUP

But what if instead you assume that I'm not using a custom implementation and compare sending JSON with a mime type of text/plain to that of mime type application/json?

Then the answer is that it makes almost no performance difference.

• You save 6 bytes in the HTTP request or response header because the mime type string is shorter, but this is insignificant for typical HTTP messages whose sizes are measured in thousands of bytes.
• Using a "text/plain" content type makes no difference to the work that needs to be done to encode / decode the request or response messages ... apart from the time taken to compare / copy 6 extra bytes, which is probably too small to measure.

In addition, using an inaccurate MIME type is (arguably) a violation of the HTTP specs. If you do this:

• it is more likely that the receiver will mishandle the response; e.g. fail to decode it, or show it in a browser window, and

• you may break HTTP content type negotiation, assuming that your client or server uses it.

In short, I can think of no good reason to do this¹, and a few good reasons not to do it.

---

^{1 - In general. Obviously, there will be edge cases ...}