是否有必要为内容提供内容类型的报头，就像对web api的PUT/POST请求中的请求报头一样

本文关键字：请求 报头 POST api PUT 一样 web 是否 类型 | 更新日期: 2023-09-27 18:03:08

我是新的web api和编写代码，我在json数据发送到web api (web服务)的PUT/POST请求。我正在执行以下操作

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);
}

我的问题是我基本上必须把内容类型的代码为内容头或不，我已经观察到，即使包含内容类型为"applicatipn/json"专门为内容类型在我的代码在Fiddler中检查我的请求，它仍然显示内容类型:text/html。为什么呢?。非常感谢您的回复

是否有必要为内容提供内容类型的报头，就像对web api的PUT/POST请求中的请求报头一样

是的，您需要为content-type添加代码。JSON中不需要包含的部分是accept，尽管我个人认为包含accept更好，因为它明确地说明了意图，但您的实际情况可能会有所不同。

这是我刚刚发现的一篇博客文章，解释了一些不这样做的问题:http://truncatedcodr.wordpress.com/2012/09/05/asp-net-web-api-always-set-content-type/

编辑:

看到评论。显然，您不再需要指定内容类型。无论如何，显式编码优于隐式编码，至少在大多数企业软件中是这样。原因很简单:当您使用隐式编码时，通常会丢失代码的意图。请注意，我并不是说"不要使用可用的抽象"，因为允许微软(或开源开发团队)接管应用程序的管道并使用他们提供的抽象来简化和减少代码并没有什么错。如果您依赖默认值，而不是设置值，那么您将在将来产生一些风险，这一点应该考虑在内。在某些情况下，冒险是值得的。现在的趋势是尽可能多地使用隐式编码，因为这样可以节省击键次数。作为一名顾问，我可以证明这往往是未来问题的核心。

相关文章：