Spring MVC内置支持的4种内容协商方式【享学Spring MVC】

每篇一句

> 十个光头九个富，最后一个会砍树

前言

不知你在使用

Spring Boot

同一个

json

html

Spring Boot

@RestController
@RequestMapping
public class HelloController {
@GetMapping("/test/error")
public Object testError() {
System.out.println(1 / 0); // 强制抛出异常
return "hello world";
}
}

使用浏览器访问：

http://localhost:8080/test/error

RESTful

ContentNegotiation

HTTP内容协商

虽然本文主要是想说

Spring MVC

HTTP

Spring MVC

定义

一个

URL资源

MediaType

方式

http

1. 服务端将可用列表（自己能提供的MIME类型们）发给客户端，客户端选择后再告诉服务端。这样服务端再按照客户端告诉的MIME返给它。（缺点：多一次网络交互，而且使用对使用者要求高，所以此方式一般不用）
2. （常用）客户端发请求时就指明需要的

   MIME

   们（比如

   Http

   头部的：

   Accept

   ），服务端根据客户端指定的要求返回合适的形式，并且在响应头中做出说明（如：

   Content-Type

   ） 1. 若客户端要求的MIME类型服务端提供不了，那就406错误吧~

常用请求头、响应头

==请求头==

Accept

text/plain

application/json

Accept-Language

Accept-Charset

Accept-Encoding

Content-Type

application/json

text/html

Content-Language

Content-Charset

Content-Encoding

Accept

Content-Type

有很多文章粗暴的解释：

Accept

Content-Type

Content-Type：application/json;charset=utf-8

Content-Type

HTTP协议规范的格式如下四部分：

1. ＜request-line＞(请求消息行)
2. ＜headers＞(请求消息头)
3. ＜blank line＞(请求空白行)
4. ＜request-body＞(请求消息体)

Content-Type

Content-Type

Spring MVC内容协商

Spring MVC

HTTP

1. HTTP

   头

   Accept

2. 扩展名
3. 请求参数
4. 固定类型（producers）

> 说明：以下示例基于Spring进行演示，而非

Spring Boot

方式一：HTTP头

Accept

@RestController
@RequestMapping
public class HelloController {
@ResponseBody
@GetMapping("/test/{id}")
public Person test(@PathVariable(required = false) String id) {
System.out.println("id的值为：" + id);
Person person = new Person();
person.setName("fsx");
person.setAge(18);
return person;
}
}

如果默认就这样，不管浏览器访问还是Postman访问，得到的都是json串。

但若你仅仅只需在

pom

<!-- 此处需要导入databind包即可， jackson-annotations、jackson-core都不需要显示自己的导入了-->
<dependency>
<groupid>com.fasterxml.jackson.core</groupid>
<artifactid>jackson-databind</artifactid>
<version>2.9.8</version>
</dependency>
<!-- jackson默认只会支持的json。若要xml的支持，需要额外导入如下包 -->
<dependency>
<groupid>com.fasterxml.jackson.dataformat</groupid>
<artifactid>jackson-dataformat-xml</artifactid>
<version>2.9.8</version>
</dependency>

再用浏览器/Postman访问，得到结果就是xml了，形如这样： > 有的文章说：浏览器是xml，postman是json。本人亲试：都是xml。

但若我们

postman

Accept：application/json

Accept

*/*

response

Accept：application/json

*/*

Chrome

Accept

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3

@ResponseBody

MediaType

消息最终都会交给

AbstractMessageConverterMethodProcessor.writeWithMessageConverters()

// @since 3.1
AbstractMessageConverterMethodProcessor：
protected <t> void writeWithMessageConverters( ... ) {
Object body;
Class<!--?--> valueType;
Type targetType;
...
HttpServletRequest request = inputMessage.getServletRequest();
// 这里交给contentNegotiationManager.resolveMediaTypes()  找出客户端可以接受的MediaType们~~~
// 此处是已经排序好的（根据Q值等等）
List<mediatype> acceptableTypes = getAcceptableMediaTypes(request);
// 这是服务端它所能提供出的MediaType们
List<mediatype> producibleTypes = getProducibleMediaTypes(request, valueType, targetType);

// 协商。 经过一定的排序、匹配  最终匹配出一个合适的MediaType
...
// 把待使用的们再次排序，
MediaType.sortBySpecificityAndQuality(mediaTypesToUse);

// 最终找出一个最合适的、最终使用的：selectedMediaType
for (MediaType mediaType : mediaTypesToUse) {
if (mediaType.isConcrete()) {
selectedMediaType = mediaType;
break;
} else if (mediaType.isPresentIn(ALL_APPLICATION_MEDIA_TYPES)) {
selectedMediaType = MediaType.APPLICATION_OCTET_STREAM;
break;
}
}
}

acceptableTypes

Accept

producibleTypes

getProducibleMediaTypes()

AbstractMessageConverterMethodProcessor：

protected List<mediatype> getProducibleMediaTypes( ... ) {
// 它设值的地方唯一在于：@RequestMapping.producers属性
// 大多数情况下：我们一般都不会给此属性赋值吧~~~
Set<mediatype> mediaTypes = (Set<mediatype>) request.getAttribute(HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
if (!CollectionUtils.isEmpty(mediaTypes)) {
return new ArrayList&lt;&gt;(mediaTypes);
}
// 大多数情况下：都会走进这个逻辑 --&gt; 从消息转换器中匹配一个合适的出来
else if (!this.allSupportedMediaTypes.isEmpty()) {
List<mediatype> result = new ArrayList&lt;&gt;();
// 从所有的消息转换器中  匹配出一个/多个List<mediatype> result出来
// 这就代表着：我服务端所能支持的所有的List<mediatype>们了
for (HttpMessageConverter<!--?--> converter : this.messageConverters) {
if (converter instanceof GenericHttpMessageConverter &amp;&amp; targetType != null) {
if (((GenericHttpMessageConverter<!--?-->) converter).canWrite(targetType, valueClass, null)) {
result.addAll(converter.getSupportedMediaTypes());
}
}
else if (converter.canWrite(valueClass, null)) {
result.addAll(converter.getSupportedMediaTypes());
}
}
return result;
} else {
return Collections.singletonList(MediaType.ALL);
}
}

可以看到服务端最终能够提供哪些

MediaType

HttpMessageConverter

jackson-dataformat-xml

xml

MappingJackson2XmlHttpMessageConverter

private static final boolean jackson2XmlPresent = ClassUtils.isPresent("com.fasterxml.jackson.dataformat.xml.XmlMapper", classLoader);

if (jackson2XmlPresent) {
addPartConverter(new MappingJackson2XmlHttpMessageConverter());
}

所以默认情况下

Spring MVC

application/xml

application/json

另外还需要注意一点：有的小伙伴说通过在请求头里指定

Content-Type：application/json

Accept

第一种协商方式是

Spring MVC

HTTP Accept

Spring MVC

• 优点：理想的标准方式
• 缺点：由于浏览器的差异，导致发送的Accept Header头可能会不一样，从而得到的结果不具备浏览器兼容性

方式二：（变量）扩展名

基于上面例子：若我访问

/test/1.xml

/test/1.json

这种方式使用起来非常的便捷，并且还不依赖于浏览器。但我总结了如下几点使时的注意事项：

1. 扩展名必须是变量的扩展名。比如上例若访问

   test.json / test.xml

   就404~

2. @PathVariable

   的参数类型只能使用通用类型（

   String/Object

   ），因为接收过来的value值就是

   1.json/
   1a4bc
   1.xml

   ，所以若用

   Integer

   接收将报错类型转换错误~ 1. 小技巧：我个人建议是这部分不接收（这部分不使用

   @PathVariable

   接收），拿出来只为内容协商使用
3. 扩展名优先级比Accept要高（并且和使用神马浏览器无关）

优缺点：

• 优点：灵活，不受浏览器约束
• 缺点：丧失了同一URL的多种展现方式。在实际环境中使用还是较多的，因为这种方式更符合程序员的习惯

方式三：请求参数

这种协商方式

Spring MVC

@Configuration
@EnableWebMvc
public class WebMvcConfig extends WebMvcConfigurerAdapter {
@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
// 支持请求参数协商
configurer.favorParameter(true);
}
}

请求URL：

/test/1?format=xml

/test/1?format=json

1. 前两种方式默认是开启的，但此种方式需要手动显示开启
2. 此方式优先级

   低于

   扩展名（因此你测试时若想它生效，请去掉url的后缀）

优缺点：

• 优点：不受浏览器约束
• 缺点：需要额外的传递format参数，URL变得冗余繁琐，缺少了REST的简洁风范。还有个缺点便是：还需手动显示开启。

方式四：固定类型（produces）

它就是利用

@RequestMapping

produces

@ResponseBody
@GetMapping(value = {"/test/{id}", "/test"}, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)
public Person test() { ... }

访问：

/test/1

它也有它很很很重要的一个注意事项：

produces

MediaType

json

/test/1.xml

format=xml

Accept

application/json或者*/*

produces

1、先解析请求的媒体类型：

1.xml

MediaType

application/xml

MediaType

HandlerMethod

producers

RequestMappingInfoHandlerMapping.handleNoMatch()

RequestMappingInfoHandlerMapping：

@Override
protected HandlerMethod handleNoMatch(...) {
if (helper.hasConsumesMismatch()) {
...
throw new HttpMediaTypeNotSupportedException(contentType, new ArrayList<>(mediaTypes));
}
// 抛出异常：HttpMediaTypeNotAcceptableException
if (helper.hasProducesMismatch()) {
Set<mediatype> mediaTypes = helper.getProducibleMediaTypes();
throw new HttpMediaTypeNotAcceptableException(new ArrayList&lt;&gt;(mediaTypes));
}
}

4、抛出异常后最终交给

DispatcherServlet.processHandlerException()

Http

handlerExceptionResolvers

DefaultHandlerExceptionResolver

protected ModelAndView handleHttpMediaTypeNotAcceptable(HttpMediaTypeNotAcceptableException ex,
HttpServletRequest request, HttpServletResponse response, @Nullable Object handler) throws IOException {

response.sendError(HttpServletResponse.SC_NOT_ACCEPTABLE);
return new ModelAndView();
}

>

Spring MVC

有了关于

Accept

produces

getProducibleMediaTypes()

protected List<mediatype> getProducibleMediaTypes( ... ){
Set<mediatype> mediaTypes = (Set<mediatype>) request.getAttribute(HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE);
if (!CollectionUtils.isEmpty(mediaTypes)) {
return new ArrayList&lt;&gt;(mediaTypes);
}
...
}

因为设置了

producers

!xxx

优缺点：

• 优点：使用简单，天然支持
• 缺点：让

  HandlerMethod

  处理器缺失灵活性

Spring Boot默认异常消息处理

再回到开头的

Spring Boot

Spring Boot

Spirng Boot

/error

BasicErrorController

@Controller
@RequestMapping("${server.error.path:${error.path:/error}}")
public class BasicErrorController extends AbstractErrorController {
...
// 处理类浏览器
@RequestMapping(produces = "text/html")
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {
...
return (modelAndView != null ? modelAndView : new ModelAndView("error", model));
}

// 处理restful/json方式
@RequestMapping
@ResponseBody
public ResponseEntity<map<string, object>&gt; error(HttpServletRequest request) {
Map<string, object> body = getErrorAttributes(request, isIncludeStackTrace(request, MediaType.ALL));
HttpStatus status = getStatus(request);
return new ResponseEntity<map<string, object>&gt;(body, status);
}
...
}

有了上面的解释，对这块代码的理解应该就没有盲点了~

总结

内容协商在

RESTful

一般情况下，我们为了通用都会使用基于Http的内容协商（Accept），但在实际应用中其实很少用它，因为不同的浏览器可能导致不同的行为（比如

Chrome

Firefox

相关阅读

【小家Spring】Spring MVC容器的web九大组件之---HandlerMapping源码详解(二)---RequestMappingHandlerMapping系列

ContentNegotiation内容协商机制(一)---Spring MVC内置支持的4种内容协商方式【享学Spring MVC】 ContentNegotiation内容协商机制(二)---Spring MVC内容协商实现原理及自定义配置【享学Spring MVC】 ContentNegotiation内容协商机制(三)---在视图View上的应用：ContentNegotiatingViewResolver深度解析【享学Spring MVC】

知识交流

==The last：如果觉得本文对你有帮助，不妨点个赞呗。当然分享到你的朋友圈让更多小伙伴看到也是被

作者本人许可的~

若对技术内容感兴趣可以加入wx群交流：

Java高工、架构师3群

fsx641385712

"java入群"

转载于:https://my.oschina.net/fangshixiang/blog/3098438

• 点赞
• 收藏
• 分享
• 文章举报