JQuery Ajax is client side framework that consists of a set of methods that raise a request asynchronously to the server.

1. Ajax (jquery)
One of the biggest advantages that Ajax has in web pages is that it can access information on
the server without having to reload the web page. This means that to retrieve or update one
small piece of information only that information needs to be passed to and from the server
instead of having to redownload the entire web page.
There are two ways that Ajax can access the server. These are synchronous (where the script
stops and waits for the server to send back a reply before continuing) and asynchronous (where
the script allows the page to continue to be processed and will handle the reply if and when it
arrives).
Processing your request synchronously is a bit like reloading the page but with only the
requested information having to be downloaded instead of the entire page. This method is
therefore somewhat faster than not using Ajax since the information to be downloaded should
be significantly smaller and hence faster to retrieve than downloading the entire page over
again. It does however still require that your visitor wait for the download to occur. While your
visitors are used to having to wait for entire web pages to download, they are not used to
having to wait while interacting with a web page for any significant time and so unless the
information you are requesting is particularly small so that it can be downloaded extremely
quickly you run the risk of alienating visitors who may have been quite happy with a longer wait
to download the entire page.
Processing asynchronously avoids the delay while the retrieval from the server is taking place
because your visitor can continue to interact with the web page and the requested information
will be processed with the response updating the page as and when it arrives. For larger
requests where the response will have a noticeable delay that delay possibly will not be noticed
by your visitors because they are occupied interacting with fields further down the page. For
responses that are nearly instantaneous your visitors will not even be aware that a request to
the server was made.
The preferred way to use Ajax therefore is to use asynchronous calls where ever possible so as
to enhance your visitors experience with the web page and to avoid having the Ajax interfere
with the operation of the page. Using Ajax asynchronously is so obviously the right way that
Ajax should be used that the A in Ajax is actually considered by those who consider AJAX to be
an acronym to stand for Asynchronous (although the originator of the term claims that it is not
an acronym and the letters therefore don't stand for anything).
If asynchronous calls are so much better for your visitor's experience of the page than
synchronous calls, why does Ajax provide a way to make synchronous calls at all? While
asynchronous calls will work 99.9% of the time, there are rare situations where it just doesn't
make any sense at all to allow your visitor to continue interacting with the web page until a
particular server side process completes. In many of these cases it may be better to not use

2. Ajax at all and instead just reload the entire page. The synchronous option in Ajax is there for
the small number of situations where you can't use an asynchronous call and reloading the
entire page is also inappropriate. There are not many such situations but they do exist and so
Ajax provides for them.
A trap that many beginners may fall into is to use synchronous Ajax calls where asynchronous
calls are more appropriate (as they are most of the time). The reason for this is that
synchronous calls are easier to understand how the processing works. The thing is that
asynchronous calls actually work exactly the same way except for the processing not waiting for
the response but instead just handling the response when it arrives.
The only difference when using asynchronous calls is that you can actually set up multiple Ajax
calls that overlap with a second call being made before the first has responded. This is where
asynchronous Ajax does become slightly more complicated than synchronous Ajax because you
need to make sure that each Ajax request uses a separate Ajax object rather than reusing the
same object for all your Ajax requests. If you use the same object for multiple asynchronous
Ajax calls then the response handler will only handle the first response that it receives and will
disregard any subsequent responses. With overlapping Ajax calls with the same object you have
no real way to tell whether the response that gets processed is a response to the first call or the
second. By using separate objects for each Ajax call you will have a separate response handler
for each request that will handle toe response from the request made by that object.
Using Ajax asynchronously is the better choice for most situations. If you are only making the
one Ajax call from the page then it is no different in the way you code it to what you would use
for a synchronous call except for the one parameter that identifies how the call is to be
processed. With multiple Ajax calls on the same page, the only additional complication is that
you need to create a separate Ajax object for each request. As the various Ajax libraries will all
do this for you anyway the only time that coding your Ajax to use asynchronous calls will be any
different from what you could get away with for synchronous calls is if you are coding all of the
JavaScript for the Ajax calls yourself instead of using a library to do it for you.
Get or Post
When you use Ajax to access the server without reloading the web page you have two choices on
how to pass the information for the request to the server. These two options are to use GET or
POST.
These are the same two options that you have when passing requests to the server to load a new
page with two differences. The first difference is that you are only requesting a small piece of
information instead of an entire web page. The second and most noticeable difference is that
since the Ajax request doesn't appear in the address bar there is no noticeable difference that your
visitor will see on their screen when the request is made. Calls made using GET will not expose
the fields and their values anywhere that using POST does not also expose when the call is made
from Ajax.

3. So how should we make the choice as to which of these two alternatives that we should use?
A mistake that some beginners might make is to use GET for most of their calls simply because
it is the easier of the two to code. The most noticeable difference between GET and POST calls
in Ajax is that GET calls still have the same limit on the amount of data that can be passed as
applies when requesting a new page load. The only difference is that as you are only processing a
small amount of data with an Ajax request (or at least that's how you should use it) you are far
less likely to run into this length limit from within Ajax to what you are with complete web page
loads. A beginner may reserve using POST requests for the few instances where they do need to
pass more information that the GET method allows.
The best solution when you have lots of data to pass like that is to make multiple Ajax calls
passing a few pieces of information at a time. If you are going to pass huge amounts of data all in
the one Ajax call then you would probably be better off simply reloading the entire page since
there will be no significant difference in the processing time when huge amounts of data are
involved.
So if the amount of data to be passed isn't a good reason to use for choosing between GET and
POST then what should we use to decide which to use? These two methods were in fact set up
for entirely different purposes and the differences between how they work are in part due to the
difference in what they are intended to be used for. This not only applies to using GET and
POST from Ajax but applies to these methods where ever they are used.
The purpose of GET is as its name implies - to GET information. It is intended to be used when
you are reading information to display on the page. Browsers will cache the result from a GET
request and if the same GET request is made again then they will display the cached result rather
than rerunning the entire request. This is not a flaw in the browser processing but is deliberately
designed to work that way so as to make GET calls more efficient when the calls are used for
their intended purpose. A GET call is retrieving data to display in the page and data is not
expected to be changed on the server by such a call and so re-requesting the same data should be
expected to obtain the same result.
The POST method is intended to be used where you are updating information on the server. Such
a call is expected to make changes to the data stored on the server and the results returned from
two identical POST calls may very well be completely different from one another since the
initial values before the second POST call will be different from the initial values before the first
call because the first call will have updated at least some of those values. A POST call will
therefore always obtain the response from the server rather than keeping a cached copy of the
prior response.
So rather than choosing between GET and POST based on the amount of data that you are
passing in your Ajax call, you should select between them based on what the Ajax call is actually
doing. If the call is to retrieve data from the server then use GET. If the value to be retrieved is
expected to vary over time as a result of other processes updating it then add a current time
parameter to what you are passing in your GET call so that the later calls will not use an earlier

4. cached copy of the result that is no longer correct. If your call is going to write any data at all to
the server then use POST.
In fact you should not only use these criteria for selecting between GET and POST for your Ajax
calls. You should use this as the criteria for choosing whether to use GET or POST when
processing forms on your web page as well.