什么是响应结果
响应结果就是,在客户端向服务器发出请求后,服务器根据客户端的请求参数,给出的结果,这就是一个完整的响应结果过程。
响应的结果包含的内容非常多,主要的有 HTTP Status Code,Content-Type,Content 等等,在这里不再一一赘述。
一般情况下,在 .NET MVC 中,如果是 API 接口,默认使用 JsonOutputFormatter 对结果进行格式化。
但是也不排除某些情况下,我们需要对业务进行兼容化的设置,比如部分接口使用 xml,部分接口使用自定义的格式,需求的响应是第一要务。
常见响应结果格式化器
在 .NET(介于官方改名,咱也不叫 Core 了哈) MVC中,有几种内置的常见响应结果格式化器,他们分别是:
0、OutputFormatter(基类)
1、TextOutputFormatter(基类)
2、StringOutputFormatter
3、StreamOutputFormatter
4、JsonOutputFormatter
5、XmlSerializerOutputFormatter
由于这几种常见的格式化器的存在,我们可以放心的在 .NET MVC 中使用 请求-> 响应 过程,而不必关心他具体的实现。
来自天气预报的示例
默认的响应结果格式json
private static readonly string[] Summaries = new[]
{
"Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};
private IEnumerable<WeatherForecast> GetWeatherForecast()
{
var rng = new Random();
return Enumerable.Range(1, 3).Select(index => new WeatherForecast
{
Date = DateTime.Now.AddDays(index),
TemperatureC = rng.Next(-20, 55),
Summary = Summaries[rng.Next(Summaries.Length)]
})
.ToArray();
}
[ ]
public IEnumerable<WeatherForecast> Get()
{
return GetWeatherForecast();
}
当我们请求上面的 API 接口,将得到下面的默认输出结果。
[
{
"date": "2020-10-24T17:19:05.4638588+08:00",
"temperatureC": 2,
"temperatureF": 35,
"summary": "Cool"
},
{
"date": "2020-10-25T17:19:05.464602+08:00",
"temperatureC": 18,
"temperatureF": 64,
"summary": "Sweltering"
},
{
"date": "2020-10-26T17:19:05.4646057+08:00",
"temperatureC": -14,
"temperatureF": 7,
"summary": "Mild"
}
]
这很好,是我们想要的结果。
Xml响应结果格式器
在上面的天气预报示例中,API接口默认使用了 json 格式输出响应结果。
在不改动业务代码的情况下,我们可以增加一种 xml 输出结果,具体做法就是增加一个 API 接口,然后在 startup.cs 中添加 xml 格式化器。
[ ]
[ ]
public IEnumerable<WeatherForecast> Xml()
{
return GetWeatherForecast();
}
配置 Xml 格式器 XmlDataContractSerializerOutputFormatter
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers(configure =>
{
configure.OutputFormatters.Add(new XmlDataContractSerializerOutputFormatter());
});
}
这个时候再请求 API 地址:/weatherforecast/xml ,我们将会得到的结果如下
<ArrayOfWeatherForecast xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/CustomBinder">
<WeatherForecast>
<Date>2020-10-24T17:24:19.1047116+08:00</Date>
<Summary>Scorching</Summary>
<TemperatureC>49</TemperatureC>
</WeatherForecast>
<WeatherForecast>
<Date>2020-10-25T17:24:19.1047219+08:00</Date>
<Summary>Cool</Summary>
<TemperatureC>6</TemperatureC>
</WeatherForecast>
<WeatherForecast>
<Date>2020-10-26T17:24:19.1047221+08:00</Date>
<Summary>Freezing</Summary>
<TemperatureC>-20</TemperatureC>
</WeatherForecast>
</ArrayOfWeatherForecast>
ProducesAttribute 特性(内容协定)
API 接口 /xml 的特性标注多了一个 [Produces("application/xml")]正是得益于 ProducesAttribute 特性,我们可以在 MVC 框架内随意的定制响应结果。
ProducesAttribute 和其它的特性类没有太多的区别,其基本原理就是使用用户指定的 contentType 参数(本例中为 application/xml) 到 OutputFormatters 中查找对应类型的 Formatters。
如果找到了,就使用该 Formatters 格式化响应结果,如果没有找到,就抛出 No output formatter was found for content types 的警告,同时,客户端会收到一个 406(Not Acceptable) 的响应结果。
我想要更多-自定义格式化器
没错,上面的几种常见的格式化器虽然非常好用。但是,我现在要对接一个旧的第三方客户端,该客户端采用的是 url 参数请求协议包,很明显,由于这个客户端过于年长(假装找不到维护人员),只能在服务器端进行兼容了。
不过也不用过于担心,开发一个自定义的格式化器还是非常简单的。我们只需要定义一个继承自 TextOutputFormatter 的子类即可,其中有小部分需要编写的代码。
需求
我们接到的需求是兼容 url 方式的请求参数响应结果,经过调研,确认格式如下
key=value&key=value&key=value
需求调研清楚后,编码的速度就得跟上了
定义格式化器 WeatherOutputFormatter
public class WeatherOutputFormatter : TextOutputFormatter
{
private readonly static Type WeatherForecastType = typeof(WeatherForecast);
public WeatherOutputFormatter()
{
SupportedEncodings.Add(Encoding.UTF8);
SupportedEncodings.Add(Encoding.Unicode);
SupportedMediaTypes.Add("text/weather");
}
public override bool CanWriteResult(OutputFormatterCanWriteContext context)
{
if (context == null)
{
throw new ArgumentNullException(nameof(context));
}
if (context.ObjectType == WeatherForecastType || context.Object is WeatherForecast || context.ObjectType.GenericTypeArguments[0] == WeatherForecastType)
{
return base.CanWriteResult(context);
}
return false;
}
private string WriterText(IEnumerable<WeatherForecast> weathers)
{
StringBuilder builder = new StringBuilder();
foreach (var wealther in weathers)
{
builder.Append(WriterText(wealther));
}
return builder.ToString();
}
private string WriterText(WeatherForecast weather) => $"date={WebUtility.UrlEncode(weather.Date.ToString())}&temperatureC={weather.TemperatureC}&temperatureF={weather.TemperatureF}&summary={WebUtility.UrlEncode(weather.Summary)}";
public override async Task WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)
{
if (context == null)
{
throw new ArgumentNullException(nameof(context));
}
if (selectedEncoding == null)
{
throw new ArgumentNullException(nameof(selectedEncoding));
}
string text = string.Empty;
if (context.ObjectType == WeatherForecastType)
text = WriterText(context.Object as WeatherForecast);
else if (context.ObjectType.GenericTypeArguments[0] == WeatherForecastType)
text = WriterText(context.Object as IEnumerable<WeatherForecast>);
if (string.IsNullOrEmpty(text))
{
await Task.CompletedTask;
}
var response = context.HttpContext.Response;
await response.WriteAsync(text, selectedEncoding);
}
}
正所谓一图胜千言,所以我给大家画了一张图,方便理解
从图中可以看出,我们只需要重写两个方法,同时编写一个自定义格式化逻辑即可完成,看起来还是非常简单的。
细心的同学可能发现了,在 WriterText 方法中,考虑到兼容性的问题,我们还将 url 中的 value 进行转义,可以说还是非常贴心的哈。
编写测试方法
[ ]
[ ]
public IEnumerable<WeatherForecast> Weather()
{
return GetWeatherForecast();
}
测试方法中定义 Produces("text/weather"),指定需要的 ContentType,同时,还需要将 WeatherOutputFormatter 添加到 OutputFormatters 中使用。
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers(configure =>
{
configure.OutputFormatters.Add(new XmlDataContractSerializerOutputFormatter());
configure.OutputFormatters.Add(new WeatherOutputFormatter());
});
}
调用接口进行测试
请求 API 地址 /weather,得到结果如下
date=2020%2F10%2F27+10%3A35%3A36&temperatureC=42&temperatureF=107&summary=Scorchingdate=2020%2F10%2F28+10%3A35%3A36&temperatureC=28&temperatureF=82&summary=Freezingdate=2020%2F10%2F29+10%3A35%3A36&temperatureC=17&temperatureF=62&summary=Sweltering
结束语
至此,自定义格式化器已经完成,本文通过一个简单的示例实现,帮助大家理解如何在 MVC 中使用自定义格式化器,文章篇幅不长,做图花了点心思,欢迎您的关注。
示例代码托管在:
https://github.com/lianggx/EasyAspNetCoreDemo/tree/master/CustomBinder
本文分享自微信公众号 - dotNET跨平台(opendotnet)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
来源:oschina
链接:https://my.oschina.net/u/3772973/blog/4700052