5-1. IMPLEMENTING A UNIVERSAL WEB SERVICE ARCHITECTURE in Font

Generating Code 39 in Font 5-1. IMPLEMENTING A UNIVERSAL WEB SERVICE ARCHITECTURE

The example HTTP conversation illustrated that the browser was explicit in what it wanted. There are browsers though that do not explicitly indicate what they want, as illustrated by the following HTTP conversation. Request GET /services/historical/AMZN/2006 Accept: */* Accept-Language: en-ca Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50215; .NET CLR 1.1.4322) Connection: Keep-Alive Some browsers send the Accept type identifier */*, which essentially means, Send me whatever you ve got; I will accept it. Such a request is extremely unhelpful and makes it difficult to implement the separation of the resource from the representation. The solution to this problem is to define a default representation for the identifier */*. It s not an ideal solution, but a solution begot out of the necessity to send something. Most likely, those clients that send */* are HTML-based Web browsers. Reality of Representations and Resources Let s take a look back at Figure 4-3 and the blogging architecture. Using the architecture that separates the resources from the representation, you could define a single URL (instead of three) for the three possible representations (RSS, Atom, and HTML). Figure 4-3 showed how not to build a Web application that generated the three different formats. Is the separation of resource and representation in conflict with the discussion we ve been having thus far For the most part, the answer is yes. The separation of resource from representation is a solution when you know that the client is not an Ajax client. The difference between an Ajax client and a non-Ajax client is that the Ajax client knows how to reference and process a Web service, and the non-Ajax client doesn t. Thus for a non-Ajax client, you must send the content and formatting to the client in a single step. Now let s see whether the separation of resource from representation makes sense in an Ajax/Web service combination. Generally speaking, the separation doesn t matter. It matters only when the client is interested in receiving different Web service formats, such as CSV or JSON. This introduces the next problem, which has to do with the fact that the Internet is not based solely on Ajax clients. The Internet has oodles of different client types, so you need to be able to support all of those formats. The solution is to split the tasks into separate applications, as illustrated in Figure 5-7. The architecture contains two HTTP servers, both of which can expose themselves using the same URL. Because there are multiple HTTP servers, there will be multiple server name entries or multiple HTTP server ports. Figure 5-7 can be made more specific in terms of naming, as Figure 5-8 shows.

Figure 5-7. A complete application architecture that implements the separation of resource from representation

Figure 5-8. URLs and DNS entries of the complete architecture The DNS entry level shows a clear distinction between the individual servers, even though the URLs are completely identical. When you reference URLs, you generally don t use absolute addressing but relative referencing, as the following HTML illustrates: <a href="/services/historical/DELL/2004">Dell 2004 Historical</a>

Notice in the HTML that the href attribute doesn t specify the server gui.company.com or ws.company.com. Only the end client knows what the original server identifier is and will call the right server when resolving a URL. This gives you the flexibility to move functionality from one server to another without having to update the URLs in the application. Looking back at Figure 5-7, the browser client references the server gui.company.com and sends a request /services/trader asking for text/html. The server supporting that format generates the content automatically. While generating the content, however, the GUIServlet is acting like a mashup. A mashup is when you generate content based on content defined elsewhere. The GUIServlet consumes a data Web service to generate the GUI. Ajax and the GUI Web service consume the same data Web service, making the application data consistent. Going back to the blogger application, when the data Web service is updated internally, there is no need to update Ajax or the GUI Web service. This illustrates the next advantage of having multiple applications and HTTP servers. When generating the HTML content, you ll likely not only be pulling data from a single Web service, but you ll be generating content based on multiple Web services. Thus, you don t want a single Web service to support all representations, as the resulting Web service would be too complex and inefficient. In Figure 5-7, the mashup server gui.company.com doesn t need to generate GUI content. The mashup server could have been another Web service that generated more complex content. The idea behind using multiple Web services is to modularize the application using Web services as the contract. Going back to resources and representations, the Web service server ws.company.com can generate three types of content: JSON (application/json) XML (application/xml) CSV (application/csv) The three types of content represent the same data in three different formats. The rule of thumb for separation of resource from representation is: same data, different formats. If the representation text/html were supported on the server ws.company.com, then the Web service would have to get data from other sources and break the rule. The rule of thumb is the result of building many Web applications that make use of Web services. It s difficult and complex to build a universal Web service that can support all representations. Therefore, even though the theory says you should, it is simply not possible in practice. What is possible is the support of formats that are similar in purpose. The formats JSON, XML, and CSV are similar in that they represent data. The formats HTML, XHTML, and SWF are similar in that they represent GUI elements. In a nutshell, the separation of resource from representation makes sense when the representations have similar purposes. Supporting HTML Pages with Relative URLs Looking closely at Figure 5-8, you ll see that the idea of having GUI URLs identical to the service URLs sounds like a good idea, but it s questionable from an implementation perspective. Referencing the blog application and Figure 4-13 in particular, notice how the GUI component is referenced using the URL /blog/index.html, and the services component is referenced using the URL /services/blog/entries/current. In that particular example, the GUI URL doesn t