SpringMVC原始碼剖析(五)-訊息轉換器HttpMessageConverter
概述
在SpringMVC中,可以使用@RequestBody和@ResponseBody兩個註解,分別完成請求報文到物件和物件到響應報文的轉換,底層這種靈活的訊息轉換機制,就是Spring3.x中新引入的HttpMessageConverter即訊息轉換器機制。
Http請求的抽象
還是回到請求-響應,也就是解析請求體,然後返回響應報文這個最基本的Http請求過程中來。我們知道,在servlet標準中,可以用javax.servlet.ServletRequest介面中的以下方法:
public ServletInputStream getInputStream() throws IOException;
來得到一個ServletInputStream。這個ServletInputStream中,可以讀取到一個原始請求報文的所有內容。同樣的,在javax.servlet.ServletResponse介面中,可以用以下方法:
public ServletOutputStream getOutputStream() throws IOException;
來得到一個ServletOutputStream,這個ServletOutputSteam,繼承自java中的OutputStream,可以讓你輸出Http的響應報文內容。
讓我們嘗試著像SpringMVC的設計者一樣來思考一下。我們知道,Http請求和響應報文字質上都是一串字串,當請求報文來到java世界,它會被封裝成為一個ServletInputStream的輸入流,供我們讀取報文。響應報文則是通過一個ServletOutputStream的輸出流,來輸出響應報文。
我們從流中,只能讀取到原始的字串報文,同樣,我們往輸出流中,也只能寫原始的字元。而在java世界中,處理業務邏輯,都是以一個個有業務意義的物件為處理維度的,那麼在報文到達SpringMVC和從SpringMVC出去,都存在一個字串到java物件的阻抗問題。這一過程,不可能由開發者手工轉換。我們知道,在Struts2中,採用了OGNL來應對這個問題,而在SpringMVC中,它是HttpMessageConverter機制。我們先來看兩個介面。
HttpInputMessage
這個類是SpringMVC內部對一次Http請求報文的抽象,在HttpMessageConverter的read()方法中,有一個HttpInputMessage的形參,它正是SpringMVC的訊息轉換器所作用的受體“請求訊息”的內部抽象,訊息轉換器從“請求訊息”中按照規則提取訊息,轉換為方法形參中宣告的物件。
package org.springframework.http;
import java.io.IOException;
import java.io.InputStream;
public interface HttpInputMessage extends HttpMessage {
InputStream getBody() throws IOException;
}
HttpOutputMessage
這個類是SpringMVC內部對一次Http響應報文的抽象,在HttpMessageConverter的write()方法中,有一個HttpOutputMessage的形參,它正是SpringMVC的訊息轉換器所作用的受體“響應訊息”的內部抽象,訊息轉換器將“響應訊息”按照一定的規則寫到響應報文中。
package org.springframework.http;
import java.io.IOException;
import java.io.OutputStream;
public interface HttpOutputMessage extends HttpMessage {
OutputStream getBody() throws IOException;
}
HttpMessageConverter
對訊息轉換器最高層次的介面抽象,描述了一個訊息轉換器的一般特徵,我們可以從這個介面中定義的方法,來領悟Spring3.x的設計者對這一機制的思考過程。
package org.springframework.http.converter;
import java.io.IOException;
import java.util.List;
import org.springframework.http.HttpInputMessage;
import org.springframework.http.HttpOutputMessage;
import org.springframework.http.MediaType;
public interface HttpMessageConverter<T> {
boolean canRead(Class<?> clazz, MediaType mediaType);
boolean canWrite(Class<?> clazz, MediaType mediaType);
List<MediaType> getSupportedMediaTypes();
T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
throws IOException, HttpMessageNotReadableException;
void write(T t, MediaType contentType, HttpOutputMessage outputMessage)
throws IOException, HttpMessageNotWritableException;
}
HttpMessageConverter介面的定義出現了成對的canRead(),read()和canWrite(),write()方法,MediaType是對請求的Media Type屬性的封裝。舉個例子,當我們宣告瞭下面這個處理方法。
@RequestMapping(value="/string", method=RequestMethod.POST)
public @ResponseBody String readString(@RequestBody String string) {
return "Read string '" + string + "'";
}
在SpringMVC進入readString方法前,會根據@RequestBody註解選擇適當的HttpMessageConverter實現類來將請求引數解析到string變數中,具體來說是使用了StringHttpMessageConverter類,它的canRead()方法返回true,然後它的read()方法會從請求中讀出請求引數,繫結到readString()方法的string變數中。
當SpringMVC執行readString方法後,由於返回值標識了@ResponseBody,SpringMVC將使用StringHttpMessageConverter的write()方法,將結果作為String值寫入響應報文,當然,此時canWrite()方法返回true。
我們可以用下面的圖,簡單描述一下這個過程。
RequestResponseBodyMethodProcessor
將上述過程集中描述的一個類是org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor,這個類同時實現了HandlerMethodArgumentResolver和HandlerMethodReturnValueHandler兩個介面。前者是將請求報文繫結到處理方法形參的策略介面,後者則是對處理方法返回值進行處理的策略介面。兩個介面的原始碼如下:
package org.springframework.web.method.support;
import org.springframework.core.MethodParameter;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.support.WebDataBinderFactory;
import org.springframework.web.context.request.NativeWebRequest;
public interface HandlerMethodArgumentResolver {
boolean supportsParameter(MethodParameter parameter);
Object resolveArgument(MethodParameter parameter,
ModelAndViewContainer mavContainer,
NativeWebRequest webRequest,
WebDataBinderFactory binderFactory) throws Exception;
}
package org.springframework.web.method.support;
import org.springframework.core.MethodParameter;
import org.springframework.web.context.request.NativeWebRequest;
public interface HandlerMethodReturnValueHandler {
boolean supportsReturnType(MethodParameter returnType);
void handleReturnValue(Object returnValue,
MethodParameter returnType,
ModelAndViewContainer mavContainer,
NativeWebRequest webRequest) throws Exception;
}
RequestResponseBodyMethodProcessor這個類,同時充當了方法引數解析和返回值處理兩種角色。我們從它的原始碼中,可以找到上面兩個介面的方法實現。
對HandlerMethodArgumentResolver介面的實現:
public boolean supportsParameter(MethodParameter parameter) {
return parameter.hasParameterAnnotation(RequestBody.class);
}
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
Object argument = readWithMessageConverters(webRequest, parameter, parameter.getGenericParameterType());
String name = Conventions.getVariableNameForParameter(parameter);
WebDataBinder binder = binderFactory.createBinder(webRequest, argument, name);
if (argument != null) {
validate(binder, parameter);
}
mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
return argument;
}
對HandlerMethodReturnValueHandler介面的實現
public boolean supportsReturnType(MethodParameter returnType) {
return returnType.getMethodAnnotation(ResponseBody.class) != null;
}
public void handleReturnValue(Object returnValue, MethodParameter returnType,
ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
throws IOException, HttpMediaTypeNotAcceptableException {
mavContainer.setRequestHandled(true);
if (returnValue != null) {
writeWithMessageConverters(returnValue, returnType, webRequest);
}
}
看完上面的程式碼,整個HttpMessageConverter訊息轉換的脈絡已經非常清晰。因為兩個介面的實現,分別是以是否有@RequestBody和@ResponseBody為條件,然後分別呼叫HttpMessageConverter來進行訊息的讀寫。
如果你想問,怎麼樣跟蹤到RequestResponseBodyMethodProcessor中,請你按照前面幾篇博文的思路,然後到這裡spring-mvc-showcase下載原始碼回來,對其中HttpMessageConverter相關的例子進行debug,只要你肯下功夫,相信你一定會有屬於自己的收穫的。
思考
張小龍在談微信的本質時候說:“微信只是個平臺,訊息在其中流轉”。在我們對SpringMVC原始碼分析的過程中,我們可以從HttpMessageConverter機制中領悟到類似的道理。在SpringMVC的設計者眼中,一次請求報文和一次響應報文,分別被抽象為一個請求訊息HttpInputMessage和一個響應訊息HttpOutputMessage。
處理請求時,由合適的訊息轉換器將請求報文繫結為方法中的形參物件,在這裡,同一個物件就有可能出現多種不同的訊息形式,比如json和xml。同樣,當響應請求時,方法的返回值也同樣可能被返回為不同的訊息形式,比如json和xml。
在SpringMVC中,針對不同的訊息形式,我們有不同的HttpMessageConverter實現類來處理各種訊息形式。但是,只要這些訊息所蘊含的“有效資訊”是一致的,那麼各種不同的訊息轉換器,都會生成同樣的轉換結果。至於各種訊息間解析細節的不同,就被遮蔽在不同的HttpMessageConverter實現類中了。
相關文章
- SpringMVC原始碼剖析5:訊息轉換器HttpMessageConverter與@ResponseBody註解SpringMVC原始碼HTTP
- 【SpringMVC】HttpMessageConverter報文資訊轉換器SpringMVCHTTP
- springmvc 自定義訊息轉換器完整例子SpringMVC
- 全面剖析Android訊息機制原始碼Android原始碼
- 深入剖析 RocketMQ 原始碼 - 訊息儲存模組MQ原始碼
- 用於日期轉換的訊息轉換器
- Spring MVC 中 HttpMessageConverter 轉換器SpringMVCHTTP
- 深度剖析訊息反射機制 (轉)反射
- SpringMVC原始碼剖析(四)- DispatcherServlet請求轉發的實現SpringMVC原始碼Servlet
- jQuery原始碼剖析(五) - 事件繫結原理剖析jQuery原始碼事件
- SpringMVC原始碼剖析(二)- DispatcherServlet的前世今生SpringMVC原始碼Servlet
- RabbitMQ 入門(三)SpringAMQP訊息轉換器MQSpringGAM
- SpringMVC之原始碼分析--ViewResolver(五)SpringMVC原始碼View
- XML檔案原始碼察看器(五) (轉)XML原始碼
- 精盡Spring MVC原始碼分析 - HandlerAdapter 元件(五)之 HttpMessageConverterSpringMVC原始碼APT元件HTTP
- SpringMVC原始碼剖析(一)- 從抽象和介面說起SpringMVC原始碼抽象
- SpringMVC原始碼剖析(三)- DispatcherServlet的初始化流SpringMVC原始碼Servlet
- SpringMVC原始碼剖析(三)- DispatcherServlet的初始化流程SpringMVC原始碼Servlet
- Giraph原始碼分析(三)—— 訊息通訊原始碼
- Java集合原始碼剖析——ArrayList原始碼剖析Java原始碼
- 【Java集合原始碼剖析】ArrayList原始碼剖析Java原始碼
- 【Java集合原始碼剖析】Vector原始碼剖析Java原始碼
- 【Java集合原始碼剖析】HashMap原始碼剖析Java原始碼HashMap
- 【Java集合原始碼剖析】Hashtable原始碼剖析Java原始碼
- 【Java集合原始碼剖析】TreeMap原始碼剖析Java原始碼
- Laravel 的訊息佇列剖析Laravel佇列
- 直播原始碼網站,訊息圖示在收到訊息時展示訊息條數原始碼網站
- jQuery原始碼剖析 (二) - 選擇器jQuery原始碼
- 【Java集合原始碼剖析】LinkedList原始碼剖析Java原始碼
- 【Java集合原始碼剖析】LinkedHashmap原始碼剖析Java原始碼HashMap
- OkHttp 原始碼剖析系列(五)——代理路由選擇HTTP原始碼路由
- Runtime 從NullSafe原始碼看訊息轉發 機制Null原始碼
- RabbitMQ訊息佇列(五):Routing 訊息路由MQ佇列路由
- SpringMVC的亂碼與時間轉換SpringMVC
- 用Javascript轉換原始碼 (轉)JavaScript原始碼
- Android訊息機制原始碼分析Android原始碼
- GGTalk 開源即時通訊系統原始碼剖析之:聊天訊息防錯漏機制原始碼
- 手機直播原始碼,文字上下滾動切換 用於公告訊息提示原始碼