338 CHAPTER 11 (Shared web hosting) REST-BASED MODEL VIEW CONTROLLER
December 12th, 2007338 CHAPTER 11 REST-BASED MODEL VIEW CONTROLLER PATTERN Copy and Paste. However, with the REST-Based Model View Controller, a document processor could read an e-mail and directly process the data into a document, and vice versa. The concept of location when used with the REST-Based Model View Controller becomes irrelevant because users can access their data from home, from the office, or from anywhere else. Location is irrelevant because it is replaced with a resource. Of course, you might say, But if the resource is located at the URL http://myserver.mydomain.com/resource, the resource is locked to the server myserver.mydomain.com. What you would be missing is that myserver. mydomain.com is a server name, and a resource that is translated by a Domain Name System (DNS)2 into an IP address. It can be pointed out that a DNS server does implement a form of the Permutations pattern. By combining a DNS server with the HTTP server-based Permutations pattern implementation, you can make a URL an abstract resource. Defining an Appropriate Resource Important to the implementation of the REST-Based Model View Controller pattern is the resource used to access a view of the controller. It is tempting to simplify the pattern and generate a URL that is similar to, if not identical to, the URL used to access a model. The controller would be a mirror of the remote server, thus acting as a way to get around the same origin policy restriction. Illustrating the mirror technically, to call the Alexa search engine, you can make a REST request using the URL http://awis.amazonaws.com/onca/xml. The mirrored controller URL would be http://amazon.mydomain.com/onca/xml and would be a delegation of functionality from the controller to the model. Implementing a delegation does not implement the pattern and is an implementation of the Proxy pattern. A Proxy pattern implementation occurs when the interface exposed by the controller is identical to the interface exposed by the remote server. Note that when the word interface is mentioned, it is referenced in a code sense, and not in a user interface sense. A Proxy pattern, when implemented properly, is transparent to the client, which would suggest that the client thinks it is connected directly to the remote server. Implementing the Proxy pattern would result in an architecture identical to Figure 11-4. Figure 11-4 shows a client making a request to perform a search on the Google and Amazon.com search engines. The client communicates to the local server, which communicates to the remote servers Amazon.com and Google. If the local server acted like a proxy, the URL, request data, and response data would have to be unique for each search engine. The client would have to do the heavy lifting of figuring out what to send and how to process the response. This is wrong because the client should not need to do that. If a client were to do the heavy lifting, the JavaScript script would become large, complicated, and hard to maintain. The solution is not to let the client do the heavy lifting, but to let the controller and local clients do it. Specifically, the controller has the following responsibilities: Defining the views available to the client Defining the resources used by the client Executing and managing the local clients used to call the remote servers 2. http://en.wikipedia.org/wiki/DNS
Searching for affordable and reliable webhost to host and run your web applications? Go to our java web server services and you will be pleased.