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

Answer 1

JSON is probably going to be faster because of major optimizations(C code) to JSON-engine. For example V8's JSON.parse() is extremely fast.

Answer 2

From other advantages strings JSon formatted are similar javascript Object declaration so they permit simpler and faster parsing.

JSon string: {name:value name2:value}

Very easy to tranform to javascript Object.

Answer 3

JSON will eventually become the widely accepted format along with xml. JSON's acceptance is growing pretty quickly, which makes it a smarter choice over text , keeping the future in mind.

Answer 4

JSon is basically a format of plain text. As such it can't be faster than the best plain text format. (It could be faster than a poorly chosen plain text format) JSon is used because it makes encoding and decoding easier and is fairly human readable for many types of data, esp complex ones.

If you are looking for an alternative to which you are using now, perhaps you could give some more details of the data you are sending and we can suggest alternatives.

Answer 5

Here is the json.org description(LOL) and I couldn't agree more:

JSON: The Fat-Free Alternative to XML

Here you find there are Json libraries for almost all languages.

http://www.json.org/

Json is so easy with Jquery http://api.jquery.com/jQuery.getJSON/

One of the best texts I've found about Json http://ascherconsulting.com/what/are/the/advantages/of/using/json/

Because JSON was designed for the purpose of serializing and unserializing data being sent to and from JavaScript applications, the advantages of using JSON relate to the advantages of JSON over other means of serialization. The most well-known means of serializing data for transmission to and from applications at present is XML. Yet, XML is a rather cumbersome means of serialization. First, the sender must encode the data to be serialized based on a document type definition that the recipient understands. Doing so creates a great deal of extra padding around the actual data no matter which DTD is used. So, the size of XML documents is often fairly large in comparison with the actual set of values they contain. Second, the recipient must receive the stream of XML and decode the data in order to then put that data into memory. In comparison, the serialization of data using JSON by the sender is relatively quick and compact because the structure of JSON reflects the structure of standard programming data types and the encoding mechanism adds only the minimum number of characters required to indicate the structure and value of the data. Once the recipient receives the JSON serialized data, then, the only processing needing to be done is to evaluate the text of the string using either JavaScript's built-in eval function or a compatible function in another language. The other standard comparison is YAML, which is able to serialize complex data sets without relying upon a DTD and needs a simpler parser to both read and write than XML. However, even the simplified YAML parsers generally require more time and generate larger serialized data streams than JSON.

Answer 6

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.