Chapter 4: Data Formats 119
PART I
Encoding/Decoding Requests
When selecting an input format in an Ajax application, the big question is whether it’s easy
to get the data into the format for transmission. In the case of a traditional form-based Web
application, the browser prepares data to send to the server automatically. Sent data is nearly
always transferred as x-www-form-urlencoded name-value pairs, either in the query string
as in a GET request, or in the message body as in a POST request. However, it is certainly
possible to override this default encoding using the <form> tag’s enctype attribute.
In the case of Ajax-based applications, the preparation of data for transmission falls to
the programmer. You can stick with the traditional x-www-form-urlencoded format or use
something else if you so desire. For example, you might submit data as a JSON value, or
you might send in some well-known or even developer-defined XML format. However,
doing so may have an undesirable effect. How will the data be decoded on the server side?
Traditionally, server-side programming environments are configured to immediately
handle data submissions in the x-www-form-urlencoded format. As an example, in PHP
you can directly find values from the query or message body in the super-global $_GET[]
or $_POST[] arrays. In some environments, including older versions of PHP, the passed
values are immediately decoded and presented as variables to use within a program. When
using a different format for transmitting the data such as JSON, the same immediate
availability of submitted data on the server side will not necessarily be there. You’ll find out
later in the chapter that while it is possible to access and interpret the submitted data in
another format pretty easily, should you? Consider if the Ajax application is built to degrade
to work without JavaScript? Do you want a complex back-end that handles data submissions
in one format when JavaScript is on and another when it is off? For ease of migration from
old form-based post-and-wait style to the new Ajax style, it is likely that staying with the
traditional x-www-form-urlencoded format is the way to go. However, for the Ajax
response, we do not give the same advice.Encoding/Decoding Responses
Traditionally, server-based Web applications respond with fully baked Web pages implemented
with (X)HTML, CSS, JavaScript, and other related technologies. As we have seen, in Ajax
applications, the focus is different; instead of fully rendered pages, we return smaller
amounts of data and then update the pages or the application state more incrementally. This
begs the question: what format should be selected for sending such responses?
From a server-side encoding point of view, depending on the application architecture,
some response data formats may seem more appropriate than others. For example, if the
application traditionally generates XML and then translates it to HTML to be delivered to
the browser, it may now be easier to send the XML directly and have transformations
applied locally in the browser. However, if the application was traditionally built with full
(X)HTML pages, in the Ajax style, it might make the most sense to send small fragments of
(X)HTML markup to the browser for immediate consumption.
On the other hand, given that we are moving to a new architecture, you may wish to
more closely bind the client and server side than before. In such cases, sending JavaScript
code to be executed or JSON structures to be evaluated into JavaScript data Redundant with
“evaluated” preceding? would be called for.
The simple fact is that there isn’t some de facto format to fall back on outside of
(X)HTML, so it really is possible to use just about anything you can dream up, including