Intent
The Permutations pattern is used by the server to separate the resource (URL) from the repre- sentation (for example, HTML or XML). Separating the resource from the representation makes it possible for an end user to focus on the resource and not have to worry about the content associated with the URL. For example, if a client’s bank account is at the URL http://mydomain. com/accounts/user, the same URL can be used regardless of device (phone, PC, and so on).
Motivation
In the early days of the Web, there were applications called price comparison services. Price comparison services compared prices between multiple online vendors. The price comparison services were made possible by using screen-scraping technologies. Essentially, screen scraping involves the deciphering of the HTML content to extract the price and product information. What made screen scraping complicated was that the generated HTML content was intended for consumption by an HTML browser. Because screen scraping was inefficient, another idea arose: to create a web service that must be explicitly called by a device other than a browser. The web service and HTML content provided two different content streams for the same content.
The web service example illustrates how the same data can have multiple representations. Extrapolating the illustration a bit further, an idea would be to consider the data as a resource that can be associated with a representation. As much as we would like to have data associated with a single representation, it is not possible because each end device has its own way of representing information. A web browser loads Dynamic HTML that results in the user being presented with images, text, and links. To get more content, a user will click on a link that will load more Dynamic HTML content in the browser. Typically, you create links in Dynamic HTML by using the HTML tag <a href="somelink" />. The a tag is a built-in mechanism used by HTML to replace the currently loaded HTML content with the content referenced by the
The preceding two paragraphs discuss the problem in relatively abstract terms, and it would be better to illustrate the problem. The problem of not getting the right content can be prac- tically illustrated by using three browsers to visit two websites. Specifically, for this example I will visit the websites http://www.google.com and http://www.yahoo.com. The three browsers used are not Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari. The three browsers are indeed three completely different browser types, namely a GUI browser, a text-based browser, and a Wireless Access Protocol (WAP) browser. Each browser represents a different segment of the browsing public. The graphical browser is used by most people, text-based browsers are used by those who cannot or do not want to see the graphical HTML representations (for example, a blind or a host-terminal–based user), and the WAP browser is used by those oper- ating cell phones. Figures 5-1, 5-2, and 5-3 show snapshots of the three browsers visiting the website http://www.google.com.
Figure 5-2. Textual browser presentation of http://www.google.com
What you should notice is that the resource is the Google search engine, but the represen- tation of each resource is different. You might be tempted to believe that there is nothing special going on because http://www.google.com is a simple website and hence the represen- tation of the content is relatively simple. However, look closely at each of the figures and you will see that although the pages look similar, there are differences. Downloading the content from http://www.yahoo.com illustrates the different representations. Figures 5-4 and 5-5 show two of the browsers at the Yahoo! site.
Figure 5-4. Graphical browser presentation of http://www.yahoo.com
Yahoo! has a fairly complicated portal website and will present one of three formats depending on the browser making the request. This means that a user can call the URL http://www. yahoo.com and be presented with the appropriate content. This is how most people want their websites to function because users expect that kind of web experience. What users do not expect are experiences such as that illustrated in Figure 5-6.
In Figure 5-6, the user uses a nondefault browser and receives an error message and a message about launching another HTML content type.
Let’s take the example of the WAP content. Imagine needing to transfer some money into a bank account and being confronted with a message to launch another application that does not happen to exist on your cell phone. That would be frustrating and entirely unnecessary. Maybe some websites have other URLs for the nondefault devices, but is it the responsibility of the user to figure that out? The answer is a definite no; it is the responsibility of the website to figure that out. Frankly, it would have been better for the website to just not offer the content than to have a customer grumble and panic midway through a transaction.
Figure 5-5. WAP browser presentation of http://www.yahoo.com
The main idea behind the Permutations pattern is to present the right content at the right time. It is about creating content and presenting it appropriately based on the requirements of the end browsing device. By using the Permutations pattern, content is created like that of Google and Yahoo! From an end user perspective, that means users will need to remember only a single URL such as http://mydomain.com/bank/account/cgross, and then be assured regard- less of device that they will be presented with similar content.
Applicability
The Permutations pattern is a core pattern that can and should be used as much as possible. However, it is a pattern that requires extra work, and that extra work should not be underesti- mated. For example, both Yahoo! and Google provide a similar, but different, user interface for their mobile clients. When implementing multiple user interfaces, a significant amount of work is associated with creating each one of them. Also understand that the Permutations pattern is not only user-interface related, but should be considered device related. With respect to current URLs used by current web application frameworks, the Permutations pattern may require redefinition. This means this pattern will revisit topics that seem already solved, such as session identification and authorization.
The following contexts define when the Permutations pattern should be used:
• For the main entry points of a web application (such as http://mydomain.com/ application) or for a specific user (for example, http://mydomain.com/account/user). The idea is that if the end device and/or user has been identified, you don’t have to keep re-identifying what or whom the device is.
• For web applications that are more Internet than intranet in nature. Controlling the end devices accessing an intranet web application is easy. In contrast, it is not possible to control the end devices accessing an Internet web application, nor should any attempt be made to control them.
Associated Patterns
The Permutations pattern is the basis of all patterns defined in this book. The Content Chunking and Persistent Communications patterns use the Permutations pattern directly, and the remaining patterns use it indirectly. The only pattern that does not explicitly use this pattern is Cache Controller.
Architecture
The big-picture architecture idea behind the Permutations pattern is to separate the resource from the representation. This means that when a URL is referenced, the data that is returned from the URL is not bound to the resource. This section explains the details of why you should separate the resource from the representation and how to do that.