內容協商（Content Negotiation）

大多數響應包含一個實體，此實體包含人類用戶能理解的信息。通常，希望提供給用戶相應于請求最容易得到的實體。對服務器和緩存來說，不幸的是，并不是所有的用戶都對這個最容易得到的實體有喜好，并且并不是所有的用...

大多數響應包含一個實體，此實體包含人類用戶能理解的信息。通常，希望提供給用戶相應于請求最容易得到的實體。對服務器和緩存來說，不幸的是，并不是所有的用戶都對這個最容易得到的實體有喜好，并且并不是所有的用戶代理（如web瀏覽器）都能一致的呈現這些實體。所以，HTTP提供了一些“內容協商”機制 — 當有多個可得的表現形式的時候，對特定的響應選擇最好的表現形式的處理過程。

注意：沒有稱做“格式協商”（譯注：“格式”指的是“媒體類型”）的，因為可替換的表現形式可能會同原來的有相同的媒體類型，只是利用了此媒體類型不同的性質，例如一種不同的語言。

任何包含一個實體主體的響應包括錯誤響應都可能會受協商的支配。

有兩種類型的內容協商在HTTP中：服務器驅動協商和代理驅動協商。這兩種類型的協商具有正交性并且能被單獨使用或聯合使用。一個聯合使用方法的協商會被叫做透明協商，當緩存利用代理驅動協商的信息的時候，此代理驅動協商的信息被為后續請求提供服務器驅動協商的源服務器提供。

一、服務器驅動協商（Server-driven Negotiation）

如果響應的最好的表現形式的選擇是通過服務器上的算法來實現，那么這種方式的協商稱做服務器驅動協商。選擇是基于響應可得的表現形式（根據不同的維度，響應會不同；例如，語言，內容編碼，等等）和請求消息里特定的頭域或關于請求的其他信息（如：網絡客戶端的地址）。

服務器驅動協商是有優點的，當從可行的表現形式里進行選擇的算法對用戶代理進行描述是比較困難的時候（譯注：代理驅動協商），或者當服務器期望發送“最好的猜測”給客戶端而只通過一個響應（以避免后續請求的回路（一個請求會返回一個響應）延遲如果此“最好的猜測“對用戶適合的時候）的時候。為了改善服務器的猜測，用戶代理應該包含請求頭域（Accept，Accept-Language，Accept-Encoding，等等），這些頭域能描述它對響應的喜好。

服務驅動協商有如下缺點：

1. 對服務器不可能確切的決定對用戶來說什么是最好的，因為那需要對用戶代理和用戶對此響應目的的全面理解（如：用戶到底想把響應展示到屏幕還是打印到紙上？）。

2. 使用戶代理描述請求里的能力是非常無效的（假設只有響應的一小部分有多個表現形式）還有會侵犯用戶的隱私。

3. 使源服務器的實現變得復雜，也對為請求產生響應的算法實現變得復雜。

4. 可能會限制公有緩存（public cache）為多個客戶請求利用相同響應的能力

HTTP/1.1包含下面的請求頭域來使服務器驅動協商啟動，這些請求頭域描述了用戶代理的能力和用戶喜好：Accept，Accept-Charset，Accept-Encoding，Accept-Language,和User-Agent。然而，一些源服務器并不只局限于這些維度，這些服務器能基于請求的任何方面來讓響應不同，這些方面包括請求頭域之外的信息或在此規范里沒有定義的擴展頭域。

Vary頭域能被用來表達服務器選擇表現形式（representation）利用的參數，表現形式受服務器驅動協商的支配。

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”.

二、代理驅動協商（Agent-driven Negotiation）

對代理驅動協商來說，響應的最好表現形式的選擇被用戶代理執行，這在接收到源服務器一個初始的響應后。選擇是基于響應的一系列可得的表現形式，這些表現形式被包含在初始響應的頭域或初始響應的實體主體（entity-body）里，每個表現形式被一個屬于自己的URI指定。從這些表現形式中選擇可能被自動執行（如果用戶代理有能力這樣做）或者被用戶從超文本連接菜單中手工選擇。

代理驅動協商是有優點的，當響應可能會根據一般用途的維度（如：類型，語義，編碼）而不同的時候，當源服務器不能通過查看請求而判定用戶代理能力的時候，當共有緩存（public cache）被用來分派服務器的承載和減少網絡使用的時候。

代理驅動協商也同樣存在需要第二次請求而獲得最好表現形式的缺點。第二次請求只有當緩存被使用時才是有效率的。另外，此規范沒有定義用戶代理自動選擇表現形式的機制，所以不能防止任何這樣的機制被用于HTTP/1.1

HTTP/1.1定義了300（多個選擇）和406（不接受的）狀態響應，當使用代理驅動協商時服務器不能或不愿意利用服務器驅動協商來提供一個不同的響應的是時候。

三、透明協商（Transparent Negotiation）

透明協商是服務器驅動協商和代理驅動協商的結合體。當一個緩存被提供了構成響應的一系列可得的表現形式（就像在代理驅動協商里的響應一樣）并且維度的差異能完全被緩存理解，那么此緩存變得有能力代表源服務器為那個資源的后續請求去執行服務器驅動協商。

透明協商的優點在于它能分發源服務器的協商工作并且能移去代理驅動協商的第二次請求的延遲，因為緩存能正確的猜測到合適的響應。

此規范沒有定義透明協商的機制，所以，它不能防止任何這樣的機制被用于HTTP/1.1。

ASP.NET Web API支持內容協商：客戶端和服務器可以一起從API返回的數據，以確定正確的格式. 我們提供了默認的XML支持, JSON的, 和表格的URL編碼格式, 你可以擴展這種支持，通過添加自己的格式化, 甚至取代默認內容的談判策略.

ASP.NET Web API的內容協商具體請看：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