Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
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.
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.
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.
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.
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.
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.
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.
