| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
HTTP Content Negotiation and "Quality Values" (Page 2 of 3) Comparing Negotiation Methods To draw an analogy, suppose a co-worker offers to go out at lunch-time to pick up lunch for the two of you, at a new restaurant where neither of you have eaten before. You could provide him with some parameters regarding what you like to eatI like roast beef sandwiches, fish & chips, and pizza, but not chickenand then trust him to pick something you will like. Or, he could go to the restaurant, call you on his cell phone, and read the menu to you and let you make a selection. This first is like server-driven negotiation; the second, like agent-driven negotiation. I think this is a good analogy not only because it (hopefully) helps you see the differences between the two methods, but it also highlights the key advantages and disadvantages of each. Trusting your co-worker with your lunch selection is simple and efficient, but not foolproof. Its possible that the restaurant may not have any of the items you specified, or that your friend may get you something containing another ingredient that you dont like but that you forgot to mention. Similarly, server-based negotiation is a best-guess process that does not guarantee that the client will receive the resource in the format it wants. This is exacerbated by the fact that there are only so many ways for the client to specify its preferences using a handful of request headers. Agent-based negotiation, on the other hand, allows the client to select exactly what it wants from the available choices, just as you can choose your favorite dish from the menu of the restaurant. The problem here is that it is inefficient, because two requests and responses are required for each resource access. (Would you really want to read a restaurants menu over the phone to someone so they could choose their ideal dish? J)
In practice, server-based negotiation is the type that is most commonly used today. The client specifies its preferences using a set of four request headers that indicate what it would prefer in the representation of the resource. The headers each represent one characteristic of a resource: Accept (media type); Accept-Charset (character set); Accept-Encoding (content encoding); and Accept-Language (resource language). Any or all of these may be included in the request. Each Accept- header contains a list of acceptable values that is appropriate to the characteristic that it specifies, separated by a comma. For example, the Accept header lists media types the client considers acceptable, while Accept-Language contains language tags. Suppose you have a friend who is trilingual in English, French and Spanish. She can read a particular document in any of these languages, so she might instruct her browser to include the following header in her requests: Accept-Language: en, fr, sp
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |