Encoding the sent data

The only real issue with the data sent to the server is how it is coded into a query string.

The default content type for Get, Post and Put is application/x-www-form-urlencoded which means that the data is sent as a stream of key value pairs using URL encoding and the UTF-8 chracter encoding. We will return to character encoding in a later chapter. 

You can send data in other formats but only using Post or Put - more about how to do this later. 

In most cases form-urlencoded data is the one to stick with because it is more or less automatic at both the client and the server end of the request. If you are deriving data from a form then it will be automatically encoded for you. If you get the data from some other source then it has to be encoded.

This task is performed by the param() method.

If the data is a string then it is assumed to be in the correct format for a query string. For example:

options.data="first=ian&last=elliot";

If the data is an object then it will be converted to the query string by the param() method:

options.data={first:"ian",last:"elliot"};

results in the same query string as given earlier. 

If the data is an array then it has to be an array of key value objects each object giving the name of the key and the value. For example to code the data used in the previous examples;

options.data=[
               {name:"first",value:"ian"},
               {name:"last",value:"elliot"}
             ]

Notice that the array has one element for each of the key value pairs. You can see that this is a longer way of specifying the data but sometimes it is more convenient. 

As well as converting the data to a query string format also notice that the usual URL encoding is performed to represent characters that are not in the ASCII character set. So for example a space is replaced by %20, " by %22 and so on. If you decide to send the query string as a string that you construct yourself you need to make sure that it is URL encoded.  

So far so simple. 

However jQuery and many server frameworks can cope with a much more complicated data structure than a simple "flat" set of key value pairs. That is you can code into a query string something more complex. The idea is that the encoding method is called recursively to encode any value that might itself be a more complex data structure. 

For example consider:

var cdata={
         array:[1,2,3],
         object:{first:"ian",last:"elliot"}
}

This would be coded as:

array%5B%5D=1&array%5B%5D=2&array%5B%5D=
3&object%5Bfirst%5D=ian&object%5Blast%5D=elliot 

You could send this to the server and it would be received as a perfectly valid query string but reconstructing what it represents is a matter for the software you use on the server. For example in PHP reconstruction is simple:

$array=$_POST["array"];
$object=$_POST["object"];

After this $array is indeed an array and you could access $array[0] to retrieve 1 and so on . The variable $object is a PHP associative array and you can access the object fields using expressions like $object["first"]. 

Notice that this only works because PHP supports recursive query strings. 

If you don't want this recursive coding simply set the option traditional to true. 

Recursive encoding seems attractive but the big problem with it is that there is no agreed standard. It works with PHP and Ruby but other languages and frameworks might not support it. This is fine when  you control both the client and the server side of the interaction but it does make your code less portable.

A better alternative is to use JSON to code the data and make a JSON Ajax request.

General objects as data - processData

Finally we come to the strange and misunderstood processData.

If you set this to false then jQuery will not process what ever you store in the data option. That is no conversion to string and no encodings are performed. 

What possible purpose could this serve?

It first it seems that the only data you could send with processData set to false is string data because this is what the Ajax request requires - the Ajax request can only send formatted string data. As string data is never processed by jQuery Ajax there seems to be little point in setting processData to false when sending it. 

This of course forgets the simple fact that every JavaScript object has a string value as determined by its toString method.

When you set data to a general object other than a string with processData set to true jQuery attempts to process the object to create a query string. 

When you set data to a general object other than a string with processData set to false jQuery doesn't process the object. The object is passed to the Ajax call exactly as it is and used as if it was a String. This by default calls the toString method and sends the result to the sever as the data in the Ajax request. 

In this way any object can be the data in an Ajax request as long as it returns a sensible string value from toString. 

For example, suppose you define an object:

myObject={}
myObject.toString=function(){
               return "first=ian&last=elliot"
                  };

You can see that the string value of myObject is a vaild query string correctly encoded. Now if you set the relevant part options to: 

options.data=myObject;
options.processData=false;                   

and send the Ajax request myObject will not be processed to a string but when the Ajax call is made its toString method will be called and the query string will be sent as data.

Using this technique you can extend the range of objects that can be sent via Ajax to the server. Simply define your custom object, define its toString method to serialize the object or the data it represents and use it with processData set to false.

There are already some objects in JavaScript that can be sent in this way because they have correct serializations defined as their toString methods. Perhaps the best known is the FormData object which can be used to build up key value pairs either in code or from an HTML form.