現(xiàn)象演示

假設有一個需求是根據終端的不同，返回不同形式的數(shù)據，比如 PC 端需要以 HTML 格式返回數(shù)據，APP、小程序端需要以 JSON 格式返回數(shù)據。這時我們是 coding 幾個相似的接口？還是在一個接口里面做復雜判斷處理？兩個方案貌似都不理想，一旦需求改動，維護的東西就比較多，這時候我們利用 SpringBoot 的內容協(xié)商功能，就可以很好的簡化邏輯，案例演示如下：

創(chuàng)建實體類Dog

public class Dog {
    private String name;

    public Dog() {

    }

    public Dog(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "Dog{" +
                "name='" + name + '\'' +
                '}';
    }
}

創(chuàng)建Controller

@RestController
@RequestMapping("/content_negotiation")
public class ContentNegotiationController {

    @GetMapping("/simple")
    public Dog getDog() {
        return new Dog("wangcai");
    }
}

開啟參數(shù)形式內容協(xié)商

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true

添加POM依賴 （讓 SpringBoot 有返回相關格式數(shù)據的能力） 

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

請求及響應

返回 JSON 格式的數(shù)據

返回 HTML 格式的數(shù)據

源碼解析

HandlerMethodReturnValueHandlerComposite#handleReturnValue

總體分為兩步：

• 選擇一個 HandlerMethodReturnValueHandler 來處理當前返回值
• 處理返回值

選擇 HandlerMethodReturnValueHandler

SpringBoot 會手動注冊的一些 HandlerMethodReturnValueHandler ，一共有15 個 （SpringBoot 版本 2.6.13），我們主要關注 RequestResponseBodyMethodProcessor 這個handler。

RequestResponseBodyMethodProcessor#supportsReturnType

如果接口方法含有 @ResponseBody 注解，或者相關Controller上含有 @ResponseBody 注解，則RequestResponseBodyMethodProcessor 都可以處理

處理返回值

writeWithMessageConverters 方法大概有以下幾個步驟：

• 獲取 acceptableTypes
• 獲取 producibleTypes
• 獲取 mediaTypesToUse
• 給 mediaTypesToUse 排序
• 獲取 selectedMediaType
• 寫出數(shù)據

獲取 acceptableTypes

分為兩個分支：

• Response 是否指定 Content-Type，并且 Content-Type 的類型不是 */*，則直接跳轉到步驟6 （寫出數(shù)據）
• 獲取 acceptableTypes

AbstractMessageConverterMethodProcessor#getAcceptableMediaTypes

默認情況下，只有 HeaderContentNegotiationStrategy ，因為我們在現(xiàn)象演示的時候，將屬性 spring.mvc.contentnegotiation.favor-parameter 設置為 true，所以多出來一個 ParameterContentNegotiationStrategy 。如果 ParameterContentNegotiationStrategy 的 resolveMediaTypes 方法的返回值不為 null 且不為 MEDIA_TYPE_ALL_LIST，則以 ParameterContentNegotiationStrategy 的 resolveMediaTypes 方法返回值為準，即 ParameterContentNegotiationStrategy 的優(yōu)先級高于 HeaderContentNegotiationStrategy

ParameterContentNegotiationStrategy#resolveMediaTypes

getMediaTypeKey

默認情況下，parameterName 的值為 format

修改 parameterName 默認值

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true
      parameter-name: custom_format

resolveMediaTypeKey

就是以 parameterName 對應的屬性值為 key， 從 URL 中獲取 value，再以該 value 為 mediaTypeKey 從一個 map （mediaTypes）中獲取 MediaType

mediaTypes的初始賦值

WebMvcConfigurationSupport#mvcContentNegotiationManager

因為我們在現(xiàn)象演示的時候添加了相關POM依賴，所有 mediaTypes 的 內容如下所示：

即默認情況下，format 的參數(shù)值含義如下 ：

• json：acceptableTypes 為 [ application/json ]
• xml：acceptableTypes 為 [ application/xml ]
• 其他：acceptableTypes 為 [ */*]

也可以自定義key，配置如下所示，這時候如果參數(shù)攜帶 custom_format=lanyu，系統(tǒng)也會返回 application/xml 格式的數(shù)據

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true
      parameter-name: custom_format
      media-types: {lanyu : application/xml}

HeaderContentNegotiationStrategy#resolveMediaTypes

HeaderContentNegotiationStrategy 的 resolveMediaTypes 方法比較簡單，就是獲取請求頭中 Accept 的值

獲取 producibleTypes

大概分為以下幾種情況

Request 域的 HandlerMapping.PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE 是否為 null

屬性值不為 null：返回指定的 mediaTypes

屬性值為 null

• 是否存在 messageConverters 的 canWrite 方法返回 true
  • 存在：相關 messageConverters 的 getSupportedMediaTypes 方法返回值的集合
  • 不存在：MediaType.ALL

獲取 mediaTypesToUse

主要通過 isCompatibleWith 方法判斷  acceptableType 和 producibleType 是不是兼容的，主要有以下幾種情況 ：

producibleType 為  null：返回false

producibleType 不為null

• acceptableType 為 */* 或  producibleType為 */* ：返回true
• acceptableType 和 producibleType 都不為 */*
  • acceptableType 和 producibleType 的 type 一致
    • acceptableType 和 producibleType 的 subtype 一致 : 返回true
    • acceptableType 和 producibleType 的 subtype 不一致
      • acceptableType 或 producibleType 的 subtype 的 isWildcardSubtype 方法返回true
        • acceptableType 或 producibleType 的 subtype 為 *：返回true
        • acceptableType 的 subtype 以 *+ 開頭，并且 acceptableType 的后綴與producibleType一致：返回true
        • producibleType 的 subtype 以 *+ 開頭，并且 producibleType 的后綴與acceptableType 一致：返回true
        • 其他情況：返回false
      • acceptableType 與 producibleType 的 subtype 的 isWildcardSubtype 方法都返回false：返回false
  • acceptableType 和 producibleType 的 type 不一致：返回false

給 mediaTypesToUse 排序

排序規(guī)則1：

• 權重越大優(yōu)先級越高
• 參數(shù)個數(shù)越多優(yōu)先級越高

如果排序規(guī)則1未判斷出誰的優(yōu)先級高，則使用排序規(guī)則2，排序規(guī)則2如下：

• 權重越大優(yōu)先級越高
• type類型不為 *
• subtype類型不為 * 或以 *+ 開頭
• 參數(shù)個數(shù)越多優(yōu)先級越高

獲取 selectedMediaType

遍歷上一步經過排序的 mediaTypes，如果存在一個 mediaType 滿足以下條件，則直接返回

• type 類型不為 * ，subtype 類型不為 * 且不以 *+ 開頭

• MediaType 為 */* 或 application/*

寫出數(shù)據

如果存在一個 HttpMessageConverter 的 canWrite 方法返回 true，則使用 HttpMessageConverter 的 write 方法寫出數(shù)據

擴展：自定義HttpMessageConverter處理自定義協(xié)議

創(chuàng)建實體類Cat

public class Cat {
    private String name;

    public Cat() {

    }

    public Cat(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "Cat{" +
                "name='" + name + '\'' +
                '}';
    }
}

創(chuàng)建自定義HttpMessageConverter

public class LanyuHttpMessageConverter implements HttpMessageConverter {

    @Override
    public boolean canRead(Class clazz, MediaType mediaType) {
        return false;
    }

    @Override
    public boolean canWrite(Class clazz, MediaType mediaType) {
        if (Cat.class == clazz) {
            return true;
        }
        return false;
    }

    @Override
    public List<MediaType> getSupportedMediaTypes() {
        return Collections.singletonList(MediaType.parseMediaType("lanyu/custom"));
    }

    @Override
    public Object read(Class clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException {
        return null;
    }

    @Override
    public void write(Object o, MediaType contentType, HttpOutputMessage outputMessage) throws IOException, HttpMessageNotWritableException {
        try {
            Cat cat = (Cat) o;
            String data = "cat = {name : " + cat.getName() + "}";

            OutputStream outputStream = outputMessage.getBody();
            outputStream.write(data.getBytes());
            outputStream.flush();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

創(chuàng)建配置類

@Configuration
public class MessageConfig implements WebMvcConfigurer {

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        converters.add(new LanyuHttpMessageConverter());
    }
}

接口及響應

@GetMapping("/custom_protocol")
public Cat getCustomProtocolData() {
    return new Cat("tom");
}

我們也可以讓我們自定義的協(xié)議支持 URL 傳參形式，配置如下

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true
      parameter-name: custom_format
      media-types: {lanyu : lanyu/custom}

到此這篇關于SpringBoot自定義內容協(xié)商的實現(xiàn)的文章就介紹到這了,更多相關SpringBoot 內容協(xié)商內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論