脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 软件编程 → java → SpringBoot内容协商

SpringBoot自定义实现内容协商的三种策略

 更新时间：2025年04月27日 08:09:18   作者：风象南  
内容协商是HTTP协议中的一个重要概念,允许同一资源URL根据客户端的偏好提供不同格式的表示,这篇文章主要介绍了SpringBoot自定义实现内容协商的三种策略,希望对大家有一定的帮助

在项目开发中，同一资源通常需要以多种表现形式提供给不同的客户端。例如，浏览器可能希望获取HTML页面，而移动应用则可能需要JSON数据。这种根据客户端需求动态选择响应格式的机制，就是内容协商(Content Negotiation)。

内容协商能够实现同一API端点服务多种客户端的需求，大大提高了Web服务的灵活性和可复用性。作为主流的Java应用开发框架，SpringBoot提供了强大且灵活的内容协商支持，使开发者能够轻松实现多种表现形式的资源表达。

内容协商基础

什么是内容协商

内容协商是HTTP协议中的一个重要概念，允许同一资源URL根据客户端的偏好提供不同格式的表示。这一过程通常由服务器和客户端共同完成：客户端告知服务器它期望的内容类型，服务器根据自身能力选择最合适的表现形式返回。

内容协商主要依靠媒体类型(Media Type)，也称为MIME类型，如application/json、application/xml、text/html等。

SpringBoot中的内容协商架构

SpringBoot基于Spring MVC的内容协商机制，通过以下组件实现：

  • ContentNegotiationManager: 负责协调整个内容协商过程
  • ContentNegotiationStrategy: 定义如何确定客户端请求的媒体类型
  • HttpMessageConverter: 负责在Java对象和HTTP请求/响应体之间进行转换

SpringBoot默认支持多种内容协商策略，可以根据需求进行配置和组合。

策略一：基于请求头的内容协商

原理解析

基于请求头的内容协商是最符合HTTP规范的一种方式，它通过检查HTTP请求中的Accept头来确定客户端期望的响应格式。例如，当客户端发送Accept: application/json头时，服务器会优先返回JSON格式的数据。

这种策略由HeaderContentNegotiationStrategy实现，是SpringBoot的默认内容协商策略。

配置方式

在SpringBoot中，默认已启用基于请求头的内容协商，无需额外配置。如果需要显式配置，可以在application.properties或application.yml中添加：

spring:
  mvc:
    contentnegotiation:
      favor-parameter: false
      favor-path-extension: false

或通过Java配置：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        configurer
            .defaultContentType(MediaType.APPLICATION_JSON)
            .favorParameter(false)
            .favorPathExtension(false)
            .ignoreAcceptHeader(false);  // 确保不忽略Accept头
    }
}

实战示例

首先，创建一个基本的REST控制器：

@RestController
@RequestMapping("/api/products")
public class ProductController {
    
    private final ProductService productService;
    
    public ProductController(ProductService productService) {
        this.productService = productService;
    }
    
    @GetMapping("/{id}")
    public Product getProduct(@PathVariable Long id) {
        return productService.findById(id);
    }
    
    @GetMapping
    public List<Product> getAllProducts() {
        return productService.findAll();
    }
}

客户端可以通过Accept头请求不同格式的数据：

// 请求JSON格式
GET /api/products HTTP/1.1
Accept: application/json

// 请求XML格式
GET /api/products HTTP/1.1
Accept: application/xml

// 请求HTML格式
GET /api/products HTTP/1.1
Accept: text/html

要支持XML响应，需要添加相关依赖：

<dependency>
    <groupId>com.fasterxml.jackson.dataformat</groupId>
    <artifactId>jackson-dataformat-xml</artifactId>
</dependency>

优缺点分析

优点

  • 符合HTTP规范，是RESTful API的推荐实践
  • 无需修改URL，保持URL的简洁性
  • 适用于所有HTTP客户端
  • 对缓存友好

缺点

  • 需要客户端正确设置Accept头
  • 不便于在浏览器中直接测试不同格式
  • 某些代理服务器可能会修改或移除HTTP头

适用场景

  • RESTful API设计
  • 面向程序化客户端的API接口
  • 多种客户端需要相同数据的不同表现形式时

策略二：基于URL路径扩展名的内容协商

原理解析

基于URL路径扩展名的内容协商通过URL末尾的文件扩展名来确定客户端期望的响应格式。例如，/api/products.json请求JSON格式，而/api/products.xml请求XML格式。

这种策略由PathExtensionContentNegotiationStrategy实现，需要特别注意的是，从Spring 5.3开始，出于安全考虑，默认已禁用此策略。

配置方式

在application.properties或application.yml中启用：

spring:
  mvc:
    contentnegotiation:
      favor-path-extension: true
      # 明确指定路径扩展名与媒体类型的映射关系
      media-types:
        json: application/json
        xml: application/xml
        html: text/html

或通过Java配置：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        configurer
            .favorPathExtension(true)
            .ignoreAcceptHeader(false)
            .defaultContentType(MediaType.APPLICATION_JSON)
            .mediaType("json", MediaType.APPLICATION_JSON)
            .mediaType("xml", MediaType.APPLICATION_XML)
            .mediaType("html", MediaType.TEXT_HTML);
    }
}

安全注意事项

由于路径扩展策略可能导致路径遍历攻击，Spring 5.3后默认禁用。如果必须使用，建议：

使用UrlPathHelper的安全配置：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        UrlPathHelper urlPathHelper = new UrlPathHelper();
        urlPathHelper.setRemoveSemicolonContent(false);
        configurer.setUrlPathHelper(urlPathHelper);
    }
}

明确定义支持的媒体类型，避免使用自动检测

实战示例

controller无需修改，配置好扩展名策略后，客户端可以通过URL扩展名访问：

// 请求JSON格式
GET /api/products.json

// 请求XML格式
GET /api/products.xml

为了更好地支持路径扩展名，可以使用URL重写过滤器：

@Component
public class UrlRewriteFilter extends OncePerRequestFilter {
    
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                  HttpServletResponse response,
                                  FilterChain filterChain) throws ServletException, IOException {
        
        HttpServletRequest wrappedRequest = new HttpServletRequestWrapper(request) {
            @Override
            public String getRequestURI() {
                String uri = super.getRequestURI();
                return urlRewrite(uri);
            }
        };
        
        filterChain.doFilter(wrappedRequest, response);
    }
    
    private String urlRewrite(String url) {
        // 实现URL重写逻辑，例如添加缺失的文件扩展名
        return url;
    }
}

优缺点分析

优点

  • 易于在浏览器中测试不同格式
  • 不需要设置特殊的HTTP头
  • URL直观地表明了期望的响应格式

缺点

  • 不符合RESTful API设计原则（同一资源有多个URI）
  • 存在安全风险（路径遍历攻击）
  • Spring 5.3后默认禁用，需额外配置
  • 可能与某些Web框架或路由系统冲突

适用场景

  • 开发测试环境中快速切换不同响应格式
  • 传统Web应用需要同时提供多种格式
  • 需要支持不能轻易修改HTTP头的客户端

策略三：基于请求参数的内容协商

原理解析

基于请求参数的内容协商通过URL查询参数来确定客户端期望的响应格式。例如，/api/products?format=json请求JSON格式，而/api/products?format=xml请求XML格式。

这种策略由ParameterContentNegotiationStrategy实现，需要显式启用。

配置方式

在application.properties或application.yml中配置：

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true
      parameter-name: format  # 默认为"format"，可自定义
      media-types:
        json: application/json
        xml: application/xml
        html: text/html

或通过Java配置：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        configurer
            .favorParameter(true)
            .parameterName("format")
            .ignoreAcceptHeader(false)
            .defaultContentType(MediaType.APPLICATION_JSON)
            .mediaType("json", MediaType.APPLICATION_JSON)
            .mediaType("xml", MediaType.APPLICATION_XML)
            .mediaType("html", MediaType.TEXT_HTML);
    }
}

实战示例

使用之前的控制器，客户端通过添加查询参数访问不同格式：

// 请求JSON格式
GET /api/products?format=json

// 请求XML格式
GET /api/products?format=xml

优缺点分析

优点

  • 便于在浏览器中测试不同格式
  • 不修改资源的基本URL路径
  • 比路径扩展更安全
  • 配置简单，易于理解

缺点

  • 不完全符合RESTful API设计原则
  • 增加了URL的复杂性
  • 可能与应用中其他查询参数混淆
  • 对缓存不友好（同一URL返回不同内容）

适用场景

  • 面向开发者的API文档或测试页面
  • 需要在浏览器中直接测试不同响应格式
  • 公共API需要简单的格式切换机制
  • 不方便设置HTTP头的环境

组合策略实现高级内容协商

策略组合配置

在实际应用中，通常会组合多种策略以提供最大的灵活性：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        configurer
            .favorParameter(true)
            .parameterName("format")
            .ignoreAcceptHeader(false)  // 不忽略Accept头
            .defaultContentType(MediaType.APPLICATION_JSON)
            .mediaType("json", MediaType.APPLICATION_JSON)
            .mediaType("xml", MediaType.APPLICATION_XML)
            .mediaType("html", MediaType.TEXT_HTML);
    }
}

这个配置启用了基于参数和基于请求头的内容协商，优先使用参数方式，如果没有参数则使用Accept头。

自定义内容协商策略

对于更复杂的需求，可以实现自定义的ContentNegotiationStrategy：

public class CustomContentNegotiationStrategy implements ContentNegotiationStrategy {
    
    @Override
    public List<MediaType> resolveMediaTypes(NativeWebRequest request) throws HttpMediaTypeNotAcceptableException {
        String userAgent = request.getHeader("User-Agent");
        
        // 基于User-Agent进行内容协商
        if (userAgent != null) {
            if (userAgent.contains("Mozilla")) {
                return Collections.singletonList(MediaType.TEXT_HTML);
            } else if (userAgent.contains("Android") || userAgent.contains("iPhone")) {
                return Collections.singletonList(MediaType.APPLICATION_JSON);
            }
        }
        
        // 默认返回JSON
        return Collections.singletonList(MediaType.APPLICATION_JSON);
    }
}

注册自定义策略：

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        configurer.strategies(Arrays.asList(
            new CustomContentNegotiationStrategy(),
            new HeaderContentNegotiationStrategy()
        ));
    }
}

响应优化实战

针对不同表现形式提供优化的输出：

@RestController
@RequestMapping("/api/products")
public class ProductController {
    
    private final ProductService productService;
    
    // 通用的JSON/XML响应
    @GetMapping("/{id}")
    public ProductDto getProduct(@PathVariable Long id) {
        Product product = productService.findById(id);
        return new ProductDto(product);  // 转换为DTO避免实体类暴露
    }
    
    // 针对HTML的特殊处理
    @GetMapping(value = "/{id}", produces = MediaType.TEXT_HTML_VALUE)
    public ModelAndView getProductHtml(@PathVariable Long id) {
        Product product = productService.findById(id);
        
        ModelAndView mav = new ModelAndView("product-detail");
        mav.addObject("product", product);
        mav.addObject("relatedProducts", productService.findRelated(product));
        
        return mav;
    }
    
    // 针对移动客户端的精简响应
    @GetMapping(value = "/{id}", produces = "application/vnd.company.mobile+json")
    public ProductMobileDto getProductForMobile(@PathVariable Long id) {
        Product product = productService.findById(id);
        return new ProductMobileDto(product);  // 包含移动端需要的精简信息
    }
}

结论

SpringBoot提供了灵活而强大的内容协商机制，满足了各种应用场景的需求。在实际开发中，应根据具体需求选择合适的策略或组合策略，同时注意安全性、性能和API设计最佳实践。

到此这篇关于SpringBoot自定义实现内容协商的三种策略的文章就介绍到这了,更多相关SpringBoot内容协商内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

相关文章

  • JSP服务器端和前端出现乱码问题解决方案

    JSP服务器端和前端出现乱码问题解决方案

    这篇文章主要介绍了JSP服务器端和前端出现乱码问题解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2020-02-02
  • Spring中的@PostConstruct注解使用方法解析

    Spring中的@PostConstruct注解使用方法解析

    这篇文章主要介绍了Spring中的@PostConstruct注解使用方法解析,@PostConstruct注解是用来处理在@Autowired注入属性后init()方法之前,对一些零散的属性进行赋值的注解,需要的朋友可以参考下
    2023-11-11
  • spring定时器定时任务到时间未执行问题的解决

    spring定时器定时任务到时间未执行问题的解决

    这篇文章主要介绍了spring定时器定时任务到时间未执行问题的解决，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
    2021-11-11
  • java遍历读取xml文件内容

    java遍历读取xml文件内容

    这篇文章主要为大家介绍了java遍历读取xml文件内容，感兴趣的小伙伴们可以参考一下
    2016-01-01
  • SpringBoot定时任务调度与爬虫的配置实现

    SpringBoot定时任务调度与爬虫的配置实现

    这篇文章主要介绍了SpringBoot定时任务调度与爬虫的实现,使用webmagic开发爬虫，继承PageProcessor接口编写自己的处理类，process是定制爬虫逻辑的核心接口，在这里编写抽取逻辑，具体实现配置过程跟随小编一起看看吧
    2022-01-01
  • Flink DataStream基础框架源码分析

    Flink DataStream基础框架源码分析

    这篇文章主要为大家介绍了Flink DataStream基础框架源码分析，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
    2022-12-12
  • mybatis省略@Param注解操作

    mybatis省略@Param注解操作

    这篇文章主要介绍了mybatis省略@Param注解操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
    2020-11-11
  • Spring Cloud Config对特殊字符加密处理的方法详解

    Spring Cloud Config对特殊字符加密处理的方法详解

    这篇文章主要给大家介绍了关于Spring Cloud Config对特殊字符加密处理的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友可以参考下
    2018-05-05
  • 将java中的 string 类型转成 数组案例

    将java中的 string 类型转成 数组案例

    这篇文章主要介绍了将java中的 string 类型转成 数组案例，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
    2020-09-09
  • 微服务如何通过feign.RequestInterceptor传递参数

    微服务如何通过feign.RequestInterceptor传递参数

    这篇文章主要介绍了微服务如何通过feign.RequestInterceptor传递参数，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
    2022-03-03

最新评论