Although the history of the Internet is a bit longer, 1991 is the year when HyperText Transfer Protocol (HTTP), which is still used to transfer data over the Internet, was invented. In its first few initial versions, it didn’t do much more than opening and closing connections. The later versions of HTTP (version 1.0 appeared in 1996 and version 1.1 in 1999) became the protocol that now we all know and use.
HTTP is supported by all web browsers, and it does very well the job it was conceived for—retrieving simple web content. Whenever you request a web page using your favorite web browser, the HTTP protocol is assumed. So, for example, when you type www.mozilla.org in the location bar of Firefox, it will assume by default that you meant http://www.mozilla.org.
The standard document type of the Internet is HyperText Markup Language (HTML), and it is built of markup that web browsers understand, parse, and display. HTML is a language that describes documents’ formatting and content, which is basically composed of static text and images. HTML wasn’t designed for building complex web applications with interactive content or user-friendly interfaces. When you need to get to another HTML page via HTTP, you need to initiate a full page reload, and the HTML page you requested must exist at the mentioned location, as a static document, prior to the request. It’s obvious that these restrictions don’t really encourage building anything interesting.
Nevertheless, HTTP and HTML are still a very successful pair that both web servers and web clients (browsers) understand. They are the foundation of the Internet as we know it today. Figure 1.1 shows a simple transaction when a user requests a web page from the Internet using the HTTP protocol:
Three points for you to keep in mind:
HTTP transactions always happen between a web client (the software making the request, such as a web browser) and a web server (the software responding to the request, such as Apache or IIS). From now on in this book, when saying ‘client’ we refer to the web client, and when saying ‘server’ we refer to the web server.
The user is the person using the client.
Even if HTTP (and its secure version, HTTPS) is arguably the most important protocol used on the Internet, it is not the only one. Various kinds of web servers use different protocols to accomplish various tasks, usually unrelated to simple web browsing. The protocol we’ll use most frequently in this book is HTTP, and when we say ‘web request’ we’ll assume a request using HTTP protocol, unless other protocol will be mentioned explicitly.
Sure thing, the HTTP-HTML combination is very limited in what it can do—it only enables users to retrieve static content (HTML pages) from the Internet. To complement the lack of features, several technologies have been developed.
While all web requests we’ll talk about from now on still use the HTTP protocol for transferring the data, the data itself can be built dynamically on the web server (say, using information from a database), and this data can contain more than plain HTML allowing the client to perform some functionality rather than simply display static pages.
The technologies that enable the Web to act smarter are grouped in the following two main categories:
Server-side web technologies enable the web server to do much more than simply returning the requested HTML files, such as performing complex calculations, doing object-oriented programming, working with databases, and much more.
Just imagine how much data processing Amazon must do to calculate personalized product recommendations for each visitor, or Google when it searches its enormous database to serve your request. Yes, server-side processing is the engine that caused the web revolution, and the reason for which Internet is so useful nowadays.
The important thing to remember is that no matter what happens on the server side, the response received by the client must be a language that the client understands (obviously)—such as HTML, which has many limits, as mentioned earlier.
PHP is one of the technologies used to implement server-side logic. Chapter 3 will serve an introduction to PHP, and we’ll use PHP in this book when building the AJAX case studies. It’s good to know, though, that PHP has many competitors, such as ASP.NET (Active Server Pages, the web development technology from Microsoft), Java Server Pages (JSP), Perl, ColdFusion, Ruby on Rails, and others. Each of these has its own way of allowing programmers to build server-side functionality.
PHP is not only a server-side technology but a scripting language as well, which programmers can use to create PHP scripts. Figure 1.2 shows a request for a PHP page called
index.php.This time, instead of sending back the contents of
index.php, the server executes
index.php and sends back the results. These results must be in HTML, or in other language that the client understands.
On the server side you’ll usually need a database server as well to manage your data. In the case studies of this book we’ll work with MySQL, but the concepts are the same as any other server. You’ll learn the basics of working with databases and PHP in Chapter 3.
However, even with PHP that can build custom-made database-driven responses, the browser still displays a static, boring, and not very smart web document.
The need for smarter and more powerful functionality on the web client generated a separated set of technologies, called client-side technologies. Today’s browsers know how to parse more than simple HTML. Let’s see how.
Other popular technologies to perform functionality at the client side are Java applets and Macromedia Flash. Java applets are written in the popular and powerful Java language, and are executed through a Java Virtual Machine that needs to be installed separately on the system. Java applets are certainly the way to go for more complex projects, but they have lost the popularity they once had over web applications because they consume many system resources. Sometimes they even need long startup times, and are generally too heavy and powerful for the small requirements of simple web applications.
Macromedia Flash has very powerful tools for creating animations and graphical effects, and it’s the de-facto standard for delivering such kind of programs via the Web. Flash also requires the client to install a browser plug-in. Flash-based technologies become increasingly powerful, and new ones keep appearing.
Combining HTML with a server-side technology and a client-side technology, one can end up building very powerful web solutions.
So there are options, why would anyone want anything new? What’s missing?
The hidden problem with this scenario is that each time the client needs new data from the server, a new HTTP request must be made to reload the page, freezing the user’s activity. The page reload is the new evil in the present day scenario, and AJAX comes in to our rescue.