120 Part I: Core Ideas
text-encoded binary formats, comma-separated values, or little known text formats of your
own design. The only caveat being that you will have to write code to handle such responses
on the client.
Security Considerations
The relative ease of encode-decode is often as far as a developer may think when choosing a
data format. However, there are other useful considerations that could be quite critical in some
applications. For example, if the security of the transmission is a concern, it would make sense
to choose a format that was not immediately understood in case it was intercepted. You could
choose to use a data format that was not easily human readable such as base64 encoding or
even some light form of encryption to then be decrypted by the receiving JavaScript. This is, in
one sense, simple visual security—it keeps the person who intercepts the message from
instantly knowing its contents. However, do understand that it only adds a layer of decoding
hassle for someone who really wants to know what the data is.
Visual data security is obviously better than just ignoring possible interception and
sending raw values around; however, a much better solution would be to encrypt the
transmission via SSL. These techniques are not mutually exclusive; you could obfuscate the
data and transmit it using SSL, which will add more trouble for the potential interceptor.
The decision to add any form of security should follow the maxim that the effort required to
secure data should be directly correlated to the value of the data being protected.
We have previously mentioned the same origin policy that disallows XHR objects from
talking to domains other than the one they are served from. This can be both helpful and
harmful. Because the <script> tag does not have the same-origin policy, it is often
employed to get around this issue. Yet because of this, JavaScript payloads can be used by
any remote site unless steps are taken to disallow it. We’ll see specifically why there is a
need to be careful with passing script and JSON data in Chapter 7, but for now we simply
state the fact that some data formats do have security pros and cons.
Transmission Considerations
The final consideration for choosing a data format is its efficiency for transport. Some data
formats can get a bit bulky if you consider the content versus the structure. For example,
consider that when sending a simple comma-separated value, the data is quite concise.
value1, value2, value3, ... value N
Performing the same task in XML would be much bulkier like so:
<?xml version="1.0" encoding="UTF-8" ?>
<packet>
<item>Value 1</item>
<item>Value 2</tem>
...
<item>Value N</item>
</packet>
or even worse. Fortunately, in the case of Ajax, the data sent and received is often quite
small and textual so it is very easy to transparently compress it during transmission using
HTTP compression. The optimization of data transmissions will be discussed in Chapter 6,