Client-Server 101

Client-Server 101

Server side technologies have been about for a good, long while. While once Perl-CGI was the platform of choice today we have an often bewildering range of languages, application servers and databases to choose from when developing for the World Wide Web. With the advent of the mobile Web, one of the questions that periodically crops up is can we use those same technologies for this new medium?

The short answer is yes and shame on you for asking.

I suppose the latter half of that answer might seem a little harsh, but there is a good reason for it. Server side technologies are so called because they operate on a Web server. When you search for something on Google, you're not downloading their entire database of Web pages to do so, the processing takes place far, far away on one or more servers and all you get in return is your result, formatted as HTML. The same goes for server side includes or calculations or any other process that has uses the same type of technology.

This is not the same as client side technologies as these, by definition, run on your client or browser. Flash, JavaScript or applets are sent to your browser from the server and naturally if it cannot support these, it'll fail. But my point is that frankly if you're a Web developer you really should know this already as understanding the client-server model of the Internet is probably as basic a concept as there is for someone who is supposedly in the know.

However, in fairness, it's not as simple as all that and there is a pretty big caveat. Ultimately, even if a server side technology does all the clever stuff away from your browser – be it desktop or mobile – it does still send a result to it in the end. And naturally if your browser is expecting XHTML or WML, then sending HTML is going to fail.

But the main problem when using such technologies is that they've typically been optimised for the desktop Web and simplified for ease of use. The first, and most common, such issue any mobile developer will come across is content-type. Many years ago you had to send this with any and all pages that were outputted. As newer technologies began to appear, such as PHP or ASP, they were simplified so that HTML output is assumed unless otherwise overridden. Within a few short years a new generation of developers (IT generations appear to be more brief than mayflies) had already forgotten what a content-type was, so that when WAP started appearing, we found that we had learn this all over again so as to override this default HTML content type with that of WML.

Another example was the HTTP 302 redirect, also (erroneously) known as the server-side redirect. In reality it's not actually done on the server, but is a directive sent to the client telling it to go elsewhere. It simply appears to be server side because the languages that we use have packaged it into handy little functions or methods and browsers typically will carry out the directive without letting us know that the redirection was anything other than seamless. More so in the past, this naturally created problems for many developers who could not understand how something supposedly on the server could be failing on the client, typically because many did not realise how it actually worked.

Moving forward, the trend in Web technologies is to continue hiding what goes one beneath the surface of a language to make development easier and more rapid, with frameworks such as Rails or .NET further fuelling this abstraction. However, as long as we're aware of these desktop-favouring defaults and understand how be can get around them, often with the use of first principles, any server side technology can easily be adapted to work seamlessly with the mobile Web.

Gaddo F Benedetti (gaddo at gaddo dot net)