HTML and CSS Reference
In-Depth Information
AJAX
The web application we have written in this topic is largely independent of its web server.
The web server is responsible for serving resources, and providing an origin for APIs that
implement single-origin policies, but beyond that it is not playing any meaningful role, and
in fact, once the application is loaded it can exist independent of the web server.
Most real world web applications need to send or receive data to a web server at some point
in their lifecycles. For instance, users may wish to synchronize their task list in our applica-
tion between multiple devices.
There are two ways a web application can interact with a web server. The most common
approach is to perform HTTP POST or GET to the server, and load the HTTP response into
the browser.
An HTTP GET request is the most common type of request, and occurs when a page is
requested from the browser address bar, or the user clicks on a hyperlink. A GET request
specifies a specific resource, but it can also pass data to the server using name/value pairs
encoded in the URL, for instance:
http://localhost/viewprofile?username=dane
This GET request contains a single parameter (username); which has been set to a value
(“dane”).
In order to send larger quantities of data to the server POST requests are generally used. A
POST request serializes the data in an HTTP form as a set of key/value pairs. The name of
each input field becomes a key, while the current value of the input field becomes the value.
A side effect of traditional HTTP GET and POST requests is that a new web page is loaded
as a result (the HTTP response). Even if the URL does not change, and there is only a change
to a minor part of the page, there will be a lag as the HTTP request is sent and the response
is received and rendered.
A second limitation of traditional HTTP GET and POST requests is that they are synchron-
ous. It is not possible to continue using the web application while the request is in progress:
the user must wait for the response to be received and updated in the browser.
If you consider the web application we have developed, a traditional web site would cause a
page refresh when the user selects to edit a task. A GET request would be sent to the server,
perhaps:
http://localhost/tasks.html?edit=122
Search WWH ::




Custom Search