是否有内容的内容类型标头，就像对Web api的PUT / POST请求中的请求标头一样

Question

I'm new to web api and writing a code where by I'm sending in json data for a PUT/POST request to web api (web service). I'm doing the following

using (var client = new HttpClient())
{
    client.BaseAddress = new Uri("http://localhost:9000/");
    client.DefaultRequestHeaders.Accept.Clear();
    client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    var gizmo = some json data;
    HttpRequestMessage req = new HttpRequestMessage(HttpMethod.Post,"url");
    req.Content = new StringContent(some json data, Encoding.UTF8,"application/json"));
    client.Timeout = TimeSpan.FromSeconds(500);
    response = await client.PostAsJsonAsync("api/products", gizmo);
}

My question is do I essentially have to put the code for content-type for content header or not and I have observed that even if do include content-type as "applicatipn/json" exclusively for content-type in my code and check my request in Fiddler, it still shows content-type :text/html. Why is that? . All your replies will be highly appreciated

Answer 1

Yes, you do put code for content-type. The bit you don't have to include with JSON is the accepts, although I personally feel it is better to include accepts, as it explicitly states intent, but your mileage may vary.

Here is a blog post I just found that explains some of the issues around not doing this: http://truncatedcodr.wordpress.com/2012/09/05/asp-net-web-api-always-set-content-type/

EDIT:

See comments. Apparently, you do not have to specify content type any more. Regardless, explicit coding is preferred to implicit coding, at least in most Enterprise software. The reason is simple: When you use implicit coding, the intent of the code is often lost. Note that I am not saying "don't use abstractions that are available", as there is nothing wrong with allowing Microsoft (or an open source development team) to take over the plumbing of your application and use the abstractions they provide to simplify and reduce your code. If you rely on defaults, rather than set the values, you create some future risk, and this should be considered. In some cases, it is worth the risk. The tendency, today, is to use implicit coding as much as possible, as it saves keystrokes. As a consultant, I can attest this is very often the core of future problems.