The rise of Web platforms
The World Wide Web, or the Web, has been evolving in its use ever since it was introduced in the early 1990s. Each phase changed both the way developers developed Web applications, as well as our view of the Web. In this article, I will briefly run through the changes that have taken place.
Web Pages
The first wave was Web pages. The Web was initially conceived as a way to link documents by hyperlinks or URLs. Documents were published on Web servers. To retrieve and view a document, all one had to do was type the address or URL of the required document in the browser. The browser would then send a 'GET' command with the URL to the server. The Web server then sent the HTML document back to the browser to be rendered. This interaction is shown in Figure 1.
Figure 1
Just as Johann Gutenberg revolutionized the way books were printed, the Web paradigm radically changed how we shared and referenced documents. However, Web pages are static and read-only. You cannot dynamically generate reports from say a 'live' stock ticker feed. The only way to change a document is to physically edit the pages on the server.
Web Applications
The next shift came by exploiting a Web server feature called CGI or Common Gateway Interface. This is an environment inside the Web server to run programs. The CGI environment defines a standard mechanism for interfacing external program; how data is passed from the Web server to the application for processing. Now instead of entering the URL to a static Web page, you can now type the URL of a program residing on the Web server. The Web server runs the program and the output, dynamically generated HTML, from that program and is returned to the Web browser.
Another way of interacting with a CGI program is by invoking it with a HTML form. A form is rendered on the browser. The form is then submitted to the program once the user has filled in all the relevant information; the data in the form is passed as parameters to a program to be processed. Let's take the example of a program that handles user registration. When this program is executed with the appropriate data from the HTML form, the program can process the data by performing CRUD operations with respect to a database. A collection of these CGI programs can be grouped to form a Web application.
And so for the very first time, applications of all types could be delivered over the Web and accessed from within a browser. Applications were no longer tied to operating systems. Software upgrades meant updating that copy of software on the web server and not on all the computer systems and desktops that the software was installed.
Although Web applications were incredibly functional, they were not flexible; Web applications were a world unto themselves. It dictated how data was viewed, manipulated and presented. And more importantly Web applications assumed that everybody was interested in HTML because all the client's access were browsers.
Web Platforms
Web platforms did not arrive until early 2000s. In his influential doctorate thesis, "Architectural Styles and the Design of Network-based Software Architectures", Dr Roy Fielding laid the foundation of what was to be the cornerstone for a Web platform. In his thesis, Dr Fielding proposed an architecture called REpresentational State Transfer or REST for short.
In REST based systems, all resources are uniquely identifiable and can be referenced by Uniform Resource Identifier (URI). A resource can be anything from a record in a database to a program on the server, to a static document to a timer. For example, a URI of a customer record may be http://www.myserver.com/database/customer/12345.
All resources are manipulated by a small set of verbs or actions. For example, we can use a subset of HTTP methods, GET, PUT, POST and DELETE on resources. The semantics of the methods on resources is left to the application developer. A possible set of behavior when applied to our customer record could be as follows:
| |||||||||||||||
So a 'GET http://www.myserver.com/database/customer/12345' means to retrieve customer record 12345 or 'GET http://www.myserver.com/database/customer' to get all customer records.
The state or contents of a resource is transferred from the server to the client to be processed and vice versa. Finally the representation is the data format of the state; the data format can be in HTML, RSS, JSON, text or some proprietary format.
And so we have the four major REST components: resource, verbs, state transfer and representation.
Web applications built on REST principles are simple but extremely flexible. Let's say you are setting up a Web site for Singapore news and you want to allow users to read the headlines with a browser or by their favourite RSS feed reader.
Prevailing wisdom would require you to have one URL for the headlines and a separate URL for RSS feeds. However, using REST we would identify the headlines URL as a resource with three possible representations, HTML, RSS and JSON (for good measure). And since this is a read-only resource, we will only honor the GET verb. And so the news site is not only a regular Web application, but also a platform because we can extend the Web site in lots of interesting ways.
We can use, for example, the Java tray icon based RSS reader to inform us of new headlines or embed the headlines in our Web page by writing JavaScript code snippets to request the headlines in JSON format and displaying the content.
The Web platform is gaining momentum; it would not be wrong to say that old and new Web sites such as Google, Flickr, Twitter, Yahoo, "_blank"="" class="c-regularLink" target="_blank" rel="noopener nofollow">Facebook to name a few, are rapidly converting to or have converted to a platform.
In the next article, we will look at how we can access some of these sites from our custom Java application.
Lee Chuk-Munn has been programming in the Java language since 1996, when he first joined Sun Microsystems in Hong Kong. He currently works as a senior developer consultant and technology evangelist for Technology Outreach at Sun in Singapore. Chuk's focus is in Java APIs, Java EE, Java SE, and Java ME. Chuk graduated in 1987 from the Royal Melbourne Institute of Technology in Melbourne, Australia, where his favorite subject was compiler theory.