SURGIMIENTO DE LA COOPERATIVA DE MERCADEO Y CONSUMO “CAMILO TORRES”.

Now that you can authenticate a user, you can associate a shopping cart with a user. When creating a shopping cart, do not consider the shopping cart to be available at one URL. There will be many users of a site, and they will each need their own shopping cart. This means each user gets an individual shopping cart at a unique URL. This is a chicken-and-egg scenario, because if there is an individual URL for a shopping cart, how does the user get that individual URL if they do not know it in the first place? Comparing it to the mall example, it is like saying, “Yeah, we have shopping carts, but they are somewhere in this mall.” Logically all malls put their shopping carts in easy-to-reach locations. This is what has to happen online. The result is the creation of a URL that acts as a directory listing.

If the URL http://mydomain.com/shoppingcart were the easy-to-reach location, calling it would result in the following being generated:

<dir xmlns:xlink="http://www.w3.org/1999/xlink"> <cart

xlink:href="example12345" xlink:label="unlabelled"

xlink:title="Unlabelled Shopping Cart" /> </dir>

The generated result is an XML file that contains a number of contained links defined by using the XML XLink notation. Each generated link represents an available cart. Because each client requires a cart, the generated result does not need to contain all available shopping carts. The generated result needs to contain only one unique available cart. When referencing the shopping cart, the client needs to remember only the links generated in the result.

If the client is operating in anonymous mode, has not been authenticated, and has turned off cookies, the client JavaScript only needs to remember the provided shopping cart link. If the client is authenticated or has allowed cookies, the projected shopping cart links can be associ- ated with the cookie.

Another solution that allows complete anonymity and could be used very effectively is not to save the state on the server side, but on the client side. So whenever the client decides to purchase something, the shopping cart on the client is filled. To check out the items in the cart, the client references a URL and passes the cart to the server. The cart state would be volatile, but it would be a true shopping cart in that no authentication is necessary until the user is ready to check out.

If the shopping cart is based on the generated link, the cart is server side. The shopping cart could be kept for a long time, and implementing the Permutations pattern would allow users to switch devices, browsers, or locations to view their shopping carts. To make the shopping cart work properly, you need to define the Accept and Authorization headers, as illustrated by the following HTTP request:

GET /shoppingcart HTTP/1.1 Host: 192.168.1.103:8100

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; ➥

rv:1.7.5) Gecko/20041220 K-Meleon/0.9 Accept: application/xml

Authorization: Digest username="cgross", realm="Private Domain", ➥

nonce="yiLhlmf/AwA=e1bafc57a6151c77e1155729300132415fc8ad0c", ➥

uri="/browse/authenticate", algorithm=MD5, ➥

response="c9b5662c034344a06103ca745eb5ebba", qop=auth, ➥

nc=00000001, cnonce="082c875dcb2ca740"

The request is an illustration of doing multiple things at the same time and contains both authorization and representation information. The server would generate a response similar to the following: <dir xmlns:xlink="http://www.w3.org/1999/xlink"> <cart xlink:href="cgross/cart1" xlink:label="cart1" xlink:title="Shopping Cart 1" /> <cart xlink:href="cgross/cart2" xlink:label="cart2" xlink:title="Shopping Cart 2" /> <cart xlink:href="cgross/cart3" xlink:label="unlabelled"

xlink:title="Unlabelled Shopping Cart" /> </dir>

The newly generated response contains a directory listing of all shopping carts associated with the individual user cgross. The links cgross/cart1 and cgross/cart2 represent already created and manipulated carts. The link cgross/cart3 is a new cart that could be used to buy other items. The already existing carts could be old shopping experiences or shopping carts that are waiting for checkout. The big idea is that it is possible to have multiple carts that could be manipulated at different times. Or the server could implement repeat purchases based on a past shopping cart, wish lists, and so on. Using server-based carts allows a website to perform automations.

The example illustrated the available carts being generated for those who want to manip- ulate XML. If a browser references the shopping cart URL link, the following HTML content would be generated:

<html> <body>

<a href="cgross/cart1" label="cart1">Shopping Cart 1</a> <a href="cgross/cart2" label="cart2">Shopping Cart 2</a> <a href="cgross/cart3" label="unlabelled">Shopping Cart 1</a> </body>

Notice how the generated content is HTML, but that a directory listing is still generated similar to the generated XML.

Shopping carts are personal items that do not need to be associated with a generic link. Shopping carts have unique URLs that can be entirely anonymous or be associated with a user. The shopping cart illustrates how it is unnecessary to have generic URLs yet still be able to offer the same functionality, even if the user has turned off cookies.

Pattern Highlights

The purpose of the Permutations pattern is to define a component-type structure for Web applications that can be associated with a user identifier. Web applications can implement an interface-driven architecture, where the resource mimics an interface, and representation mimics an implementation. The added benefit for the developer is the ability to modularize a web application in a consistent structure.

The benefit of the pattern is best illustrated by looking at Figure 5-7, where some URLs implement the Permutations pattern, and others do not. The URLs that implement the Permuta- tions pattern are the reference URLs that clients use when accessing their functionality. A reference URL would be a user’s bank account, shopping cart, and so on. Those URLs that are part of the implementation are specific and will generally not be bookmarked by the user.

The following points are the important highlights of the Permutations pattern:

• There are two aspects of the Permutations pattern: resource separated from representation, and the definition of URLs that reference specific resources.

• Separating a resource from a representation means providing a generic URL that can be used on multiple devices or browser types. The end user needs to remember only the URL, and the appropriate content will be generated by the server, depending on the HTTP headers of the HTTP request.

• When implementing the separation of the resource from the representation, URL rewriting is commonly used. For example, the resource URL http://mydomain.com/resource is redirected to a potential representation URL http://mydomain.com/resource/content.html. • Redirected resources such as content.html do not need multiple representations. When a resource has an extension such as html, it is implied that the representation is HTML. • When defining resource URLs, they will often reference data resources such as users or bank accounts. The resource URLs are noun based, for example, http://mydomain.com/ bankaccount/maryjane. The URL rewriting component then has the additional responsi- bility of ensuring those who access a noun-based, resource-based URL have the security clearance. Security clearance is determined by the user identifier. User identifiers are not used to generate content, but to allow or disallow access to a resource.

• Cookies and HTTP authentication mechanisms are the preferred means used to imple- ment user identification.

• Sometimes when implementing the Permutations pattern it is not possible or desirable to return content solely based on the Accept HTTP header. In those instances, it is possible to specify the content that is retrieved by using a parameter in the query. An example is

http://mydomain.com/mybooks/1223?accept=text/xml. The query parameter accept is an arbitrary value and has no special value other then being illustrative in this example.

• Even though all of the examples used HTTP GET to retrieve the correct content, the same rules apply for HTTP POST because an HTTP POST can generate data.

• A URL rewriter component need not use only a single HTTP header such as Accept. A more sophisticated URL rewriter component will base its decisions on all information passed to it by the HTTP request and then make a single URL rewrite decision.

153

■ ■ ■

C H A P T E R 6