Content negotiation)

Most responses contain an entity that contains information that human users can understand. In general, you want to provide users with the entity that is the easiest to get in the request. Unfortunately for servers and caches, not all users are happy with the entity most easily obtained, and not all user proxies (such as Web browsers) these entities can be consistently presented. Therefore, HTTP provides some "content negotiation" mechanisms-when there are multiple forms of representation available, select the best form of response processing process.

Note: There is no "format negotiation" (: "format" refers to "media type"), because the replaceable representation may have the same media type as the original one, it only utilizes the different nature of this media type, for example, a different language.

Any response containing an entity body, including an error response, may be subject to negotiation.

There are two types of content negotiation in http: Server-driven negotiation and proxy-driven negotiation. The two types of negotiation are orthogonal and can be used independently or jointly. A consultation meeting on joint use is called transparent negotiation. When the cache uses proxy-driven negotiation information, the proxy-driven negotiation information is provided for the source server that subsequently requests server-driven negotiation.

1. Server-driven negotiation)

If the best form of response is selected on the serverAlgorithmIn this way, the negotiation is called server-driven negotiation. The choice is based on the form of response (the response varies according to different dimensions; for example, language, content encoding, and so on) and the specific header domain in the request message or other information about the request (such as the address of the network client ).

Server-driven negotiation has advantages. It is difficult to describe the user agent by selecting an algorithm from a feasible representation ), or when the server expects to send the "best guess" to the client and only responds with one response (to avoid the loop of subsequent requests (a request will return a response) delay if this "Best guess" is suitable for users. To improve server speculation, the user agent should contain the request header domain (Accept, accept-language, accept-encoding, and so on), which can describe its preference for response.

Service-driven negotiation has the following Disadvantages:

1. it is impossible for the server to decide exactly what is the best for the user, because it requires a comprehensive understanding of the user proxy and the user's response purpose (such: do users want to display the response to the screen or print it on paper ?).

2. The ability of the user agent to describe the request is very ineffective (assuming that only a small part of the response has multiple forms), there will be infringement of the user's privacy.

3. The implementation of the source server becomes complicated, and the implementation of algorithms that generate responses to requests becomes complicated.

4. The public cache may be limited to using the same response capability for Multiple customer requests.

HTTP/1.1 contains the following request header fields to enable server-driven negotiation. These request header fields describe the capabilities and user preferences of the User Agent: Accept, accept-charset, accept-encoding, accept-language, and User-Agent. However, some source servers are not limited to these dimensions. These servers can make different responses based on any aspect of the request, these include information not included in the request header domain or an extended header domain not defined in this specification.

The vary header can be used to express the parameters used by the server selection representation (Representation). The representation is dominated by server-driven negotiation.

• Accept:Which media types are acceptable for the response, such as "application/JSON," "application/XML," or a custom media type such as "application/vnd. Example + XML"
• Accept-charset:Which character sets are acceptable, such as UTF-8 or ISO 8859-1.
• Accept-encoding:Which content encodings are acceptable, such as gzip.
• Accept-language:The preferred natural language, such as "En-Us ".

2. Agent-driven negotiation)

For proxy-driven negotiation, the best form of response is executed by the user proxy, after receiving an initial response from the source server. Selection is a series of response-based representations that are included in the initial response header or the entity body of the initial response, each representation is specified by a URI of its own. From these representations, the options may be automatically executed (if the user agent has the ability to do so) or manually selected by the user from the Hyper Text connection menu.

Proxy-driven negotiation has advantages. When the response may vary according to the general purpose dimensions (such as type, semantics, and encoding, when the source server cannot determine the proxy capability by viewing the request, when the common cache is used to distribute server loads and reduce network usage.

Proxy-driven negotiation also has the disadvantage of needing the second request to get the best form. The second request is efficient only when the cache is used. In addition, this specification does not define a mechanism for the user agent to automatically select the form of representation, so it cannot prevent any such mechanism from being used for HTTP/1.1

HTTP/1.1 defines 300 (Multiple choices) and 406 (unacceptable) status responses, when proxy-driven negotiation is used, the server cannot or is unwilling to use the server-driven negotiation to provide a different response.

3. transparent negotiation)

Transparent negotiation is a combination of server-driven negotiation and proxy-driven negotiation. When a cache is provided with a series of available forms of response (just like the response in the proxy-driven negotiation) and dimension differences can be fully understood by the cache, the cache becomes capable of executing server-driven negotiation for subsequent requests from the source server for that resource.

The advantage of transparent negotiation is that it can split the negotiation work of the source server and the delay of the second request that can be removed from the proxy-driven negotiation, because the cache can correctly guess the appropriate response.

This specification does not define a mechanism for transparent negotiation, so it cannot prevent any such mechanism from being used for HTTP/1.1.

ASP.. NET web API supports content negotiation: the client and server can return data from the API together to determine the correct format. we provide the default XML support, JSON, and table URL encoding formats. You can extend this support by adding your own formatting, or even replacing the negotiation policy of the default content.

For details about ASP. NET web API content negotiation, refer:Http://www.asp.net/web-api/overview/formats-and-model-binding/content-negotiation

Different mediatypeformatters for same mediaheadervalue in ASP. NET web API

ASP. NET web API: query string based content formatting

Http://code.msdn.microsoft.com/ASPNET-Web-API-File-Upload-a8c0fb0d
Http://stackoverflow.com/questions/12593001/web-api-model-binding-with-multipart-formdata

Http://lonetechie.com/2012/09/23/web-api-generic-mediatypeformatter-for-file-upload/

Http://www.dotblogs.com.tw/regionbbs/archive/2010/12/20/implement.http.post.multipart.form.data.aspx