Spring框架之spring-web http源碼徹底解析

Spring框架之spring-web http源碼徹底解析

        Spring-web是Spring webMVC的基礎，由http、remoting、web三部分組成。

        http：封裝了http協議中的client/server端的request請求/response響應，編解碼，一些格式的轉換（如cbor、Rss、json、xml）。

        remoting：遠程調用，包括caucho、httpinvoker、jaxws。caucho公司提出的基於HTTP實現的兩種遠程服務Burlap和hessian。HttpInvoker是spring 框架中基於 HTTP的一個遠程調用模型，只能用於Spring框架。jaxws是Sun推出的web services協議棧。

        web：包含了和web相關的accept、bind、client、context、cors、filter、jsf、method、multipart、server、util。

        Spring-web是Spring webMVC的基礎，HTTP用於Web瀏覽器和Web服務器之間的雙工通訊，因此Spring-web http模塊又是Spring-web的基礎，它包含五個模塊：

        一、 http 封裝的基礎，如httpHeader、HttpEntity 、HttpMessage 、MediaType 、HttpMethod 、httpStatus、HttpCookie等；

        二、client端的request請求（發送出去的）及response響應（接收到的）；

        三、 server端的request請求（接收到的）及response響應（發送出去的）；

        四、格式的轉換，如json，rss，xml等。

        五、 編/解碼器。

        本文基於version爲5.2.4.BUILD-SNAPSHOT的Spring源碼版本進行分析，主要從HTTP基礎及Spring-web http五個子模塊共六部分進行分析。

1、HTTP基礎

（1）HTTP協議：HTTP（Hypertext Transfer Protocol，超文本傳輸協議）是在萬維網上進行通訊時所使用的協議方案，基於TCP/IP的應用層協議。HTTP有不少應用，最著名的就是用於Web瀏覽器和Web服務器之間的雙工通訊。客戶端向服務器發送HTTP請求，服務器在HTTP響應中回送所請求的數據。

（2）MIME類型：因特網上有數千中不一樣的數據類型，HTTP給每種要經過Web傳輸的對象都打上MIME類型的數據格式標籤。MIME類型是一種文本標記，表示一種主要的對象類型和一個特定的子類型，中間由一條斜槓分隔。如text/html標記HTML 格式的文本文檔；由text/plain標記普通的ASCII 文本文檔；image/jpeg標記JPEG 格式的圖片。

（3）URL：統一資源定位符。每一個服務器資源都有一個名字，在世界範圍內惟一的標識並定位信息資源。

（4）HTTP方法：每條HTTP請求報文都包含一個方法，這個方法告訴服務器要執行什麼動做，好比獲取一個頁面、運行一個網關程序或者刪除一個文件。五種常見的HTTP方法：

        一、GET 從服務器向客戶端發送命名資源；

        二、PUT 未來自客戶端的數據存儲到一個命名的服務器資源中去；

        三、DELETE 從服務器中刪除命名資源；

        四、POST 將客戶端數據發送到一個服務器網關應用程序；

        五、HEAD 僅發送命名資源響應中的HTTP 首部。

（5）狀態碼（HTTP Status Code）：每條HTTP響應報文返回時都會攜帶一個狀態碼，是一個三位數字的代碼，告知客戶端請求是否成功，或者是否須要採起其餘動做。

        1xx消息：這一類型的狀態碼，表明請求已被接受，須要繼續處理。

        2xx成功：這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。

        3xx重定向：這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。

        4xx客戶端錯誤：這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。

        5xx服務器錯誤：表示服務器沒法完成明顯有效的請求。

（6）HTTP報文： HTTP報文是由一行行的簡單字符串組成，都是純文本，不是二進制代碼，能夠方便進行讀寫。分爲HTTP請求和響應報文，無其餘類型的HTTP報文，請求和響應報文格式很類似，包括起始行、首部字段、主體3個部分。

        一、起始行：報文的第一行就是起始行，在請求報文中用來講明要作些什麼，在響應報文中說明出現了什麼狀況。

        二、首部字段：起始行後面有零個或多個首部字段。每一個首部字段都包含一個名字和一個值，爲了便於解析，二者之間用冒號來分隔。首部以一個空行結束。添加一個首部字段和添加新行同樣簡單。

        三、主體：空行以後就是可選的報文主體了，其中包含了全部類型的數據。請求主體中包括了要發送給Web 服務器的數據；響應主體中裝載了要返回給客戶端的數據。起始行和首部都是文本形式且都是結構化的，而主體則不一樣，主體中能夠包含任意的二進制數據，好比圖片、視頻、音軌、軟件程序，文本等。

（7）請求報文（request message）：從客戶端發往服務器的HTTP報文。

請求報文示例：

        GET/sample.Jsp HTTP/1.1

        Accept:image/gif.image/jpeg,*/*

        Accept-Language:zh-cn

        Connection:Keep-Alive

        Host:localhost

        User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

        Accept-Encoding:gzip,deflate

         

        username=jinqiao&password=1234

        一、起始行：請求報文的起始行又叫請求行，請求服務器對資源作一些操做，包含了一個方法和一個請求的URL。這個方法描述了服務器應該執行的操做，請求URL描述了要對哪一個資源執行這個方法。請求行中還包含HTTP 的版本，用來告知服務器，客戶端使用的是哪一種HTTP。上例中「GET」表明請求方法，「/sample.jsp」表示URI，「HTTP/1.1表明協議和協議的版本。

        二、請求頭：跟在起始行後面的就是零個、一個或多個HTTP 首部字段。包含客戶端的環境及請求正文相關信息。

        三、請求體：首部字段和主體之間有一個空行，表示首部字段結束，接下來是主體。上例請求正文中包含客戶提交的查詢字符串信息.

（8）響應報文（response message）：從服務器發往客戶端的報文。

響應報文示例：

        HTTP/1.0 200 OK

        Date: Sun, o1 Oct 2000 23:25:17 GMT

        Server: Apache/1.3.11 BSafe-SSL/1.38 (Unix)

        Last-modified: Tue, 04 Jul 2000 09:46:21 GMT

        Content-length: 403

        Content-type: text/html

           

        Hi! I’m a message!

        一、起始行：響應報文的起始行又稱響應行，包含了響應報文使用的HTTP 版本、數字狀態碼，以及描述操做狀態的文本形式的緣由短語。上例中：HTTP 版本爲HTTP/1.0，狀態碼爲200（表示成功），緣由短語爲OK，表示文檔已經被成功返回了。

        二、響應頭：跟在起始行後面的就是零個、一個或多個HTTP 首部字段。

        三、響應體：第三部分是可選的實體主體部分。實體的主體是HTTP 報文的負荷，就是HTTP 要傳輸的內容。能夠承載多種類型的數字數據，如圖片、視頻、HTML 文檔、軟件應用程序、信用卡事務、電子郵件等。

（9）瀏覽器經過HTTP請求服務器HTML 資源步驟：

        一、 瀏覽器從URL 中解析出服務器的主機名；

        二、瀏覽器將服務器的主機名轉換成服務器的IP 地址；

        三、瀏覽器將端口號（若是有的話）從URL 中解析出來；

        四、瀏覽器創建一條與Web 服務器的TCP 鏈接；

        五、 瀏覽器向服務器發送一條HTTP 請求報文；

        六、 服務器向瀏覽器回送一條HTTP 響應報文；

        七、關閉鏈接，瀏覽器顯示文檔。

 

2、http封裝的基礎

（1）HttpHeaders：表示HTTP報文首部，首部內容爲客戶端和服務器分別處理請求和響應提供所須要的信息。HTTP首部字段是由首部字段名和字段值構成的，中間用冒號分隔（首部字段名: 字段值）。該類同時也爲首部字段提供了get/set方法。HTTP 首部字段根據實際用途被分爲如下 4 種類型：

        一、通用首部字段（General Header Fields）：請求報文和響應報文兩方都會使用的首部。

        二、請求首部字段（Request Header Fields）：從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

        三、響應首部字段（Response Header Fields）：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

        四、實體首部字段（Entity Header Fields）：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

（2）ReadOnlyHttpHeaders：只讀類型的HTTP報文首部。繼承自HttpHeaders，只能讀取，不能寫入。

 

（3）HttpEntity：表示HTTP request或者response實體，由header首部和body主體兩部分組成。

（4）RequestEntity：繼承自HttpEntity，Request請求實體，在HttpEntity基礎上增長了兩個屬性：HttpMethod類和URI類。HttpMethod枚舉了HTTP請求報文的幾種方法：GET/HEAD/POST/PUT/PATCH/DELETE/OPTIONS/TRACE。URI（java.net.URI）表示統一資源標識符（URI）引用。HttpEntity主要被RestTemplate使用（package org.springframework.web.client，RestTemplate 對 http 的封裝相似 JdbcTemplate 對 jdbc 的封裝，可以以 rest 風格的方式，以 GET/POST/PUT/DELETE/HEAD/ OPTIONS 等不一樣的方式向服務器發起HTTP 請求）。

（5）ResponseEntity：繼承自HttpEntity，Response響應實體，在HttpEntity基礎上增長了一個屬性HttpStatus。HttpStatus枚舉了HTTP的狀態碼。1xx消息、2xx成功、3xx重定向、4xx客戶端錯誤、5xx服務器錯誤，每條HTTP響應報文返回時都會攜帶一個狀態碼，告知客戶端請求是否成功，或者是否須要採起其餘動做。一樣，該類主要被RestTemplate使用。

 

（6）HttpMessage：HTTP request請求報文和response響應報文的父接口。提供了一個方法getHeaders()，得到該報文的首部HttpHeaders。

（7）HttpRequest（extends HttpMessage）：表示一個HTTP request請求報文。在父類基礎上新增了兩個函數：getMethod()獲取報文的HttpMethod，描述了服務器應該執行的操做方法；getURI()獲取該報文的URL，描述了要對哪一個資源執行上述方法。

（8）HttpInputMessage（extends HttpMessage）：表示一條接收到的HTTP報文，從服務器端來看就是接收到request報文，從客戶端來看就是接收到response報文。在父接口HttpMessage定義的函數getHeaders()基礎上新增了一個函數getBody()，得到報文的主體，返回類型是可讀的字節輸入流InputStream（java.io.InputStream）。

（9）HttpOutputMessage（extends HttpMessage）：表示一條發送出去的HTTP報文，從服務器端來看就是發送出去的response報文，從客戶端來看就是發送出去的request報文。在父接口HttpMessage定義的函數getHeaders()基礎上新增了一個函數getBody()，得到報文的主體，返回類型是可寫的字節輸入流OutputStream（java.io.OutputStream）。

（10）StreamingHttpOutputMessage（extends HttpOutputMessage）：繼承自HttpOutputMessage，該報文容許設置一個streaming流類型的報文主體。相應的，這種報文類型也就不支持getBody()函數讀取報文主體了。

（11）ReactiveHttpInputMessage（extends HttpMessage）：一個響應式的HTTP input報文，會將這個input報文當作Publisher發佈者暴露。這個接口主要會被服務器端接收到的request請求報文類或者客戶端接收到的response響應報文類實現。reactive programming（響應式編程）是相對於imperative programming（命令式編程）而言的，一種異步編程風格，它關注數據流和變化的傳播。

（12）ReactiveHttpOutputMessage（extends HttpMessage）：一個響應式的HTTP output報文，會將這個output報文當作Publisher發送出去。這個接口主要會被服務器端發送的response響應報文類或者客戶端發送的request請求報文類實現。

（13）ZeroCopyHttpOutputMessage（extends ReactiveHttpOutputMessage）：在類ReactiveHttpOutputMessage繼承上增長了對零拷貝的文件傳輸的支持。零拷貝技術（Zero-Copy）是指將數據直接從磁盤文件複製到網卡設備中，而不須要經由應用程序之手 。零拷貝大大提升了應用程序的性能，減小了內核和用戶模式之間的上下文切換 。

 

（14）MediaType：繼承自MimeType（org.springframework.util.MimeType），在父類MimeType基礎上增長了對在HTTP規範中定義的一些高質量的參數提供的方法支持。媒體類型決定瀏覽器將以何種形式對資源進行解析。常見的媒體格式類型(<type>/<subtype>)以下：

        text/html： HTML格式

        text/plain：純文本格式

        image/gif：gif圖片格式

        application/pdf：pdf格式

        application/octet-stream：二進制流數據

        ...

 Content-Type實體頭部用於指示資源的MIME類型media type。如：

        Content-Type: text/html; charset=utf-8

        Content-Type: multipart/form-data; boundary=something

（15）MediaTypeEditor：繼承自PropertyEditorSupport（java.beans.PropertyEditorSupport），自動的把字符串類型的說明（如"text/html"）轉換成MediaType對象。

（16）MediaTypeFactory：該工廠類用來從資源句柄或者文件名中解析出MediaType對象。

（17）InvalidMediaTypeException：執行解析函數parseMediaType(String)時遇到一個非法的media type拋出的異常。

 

（18）HttpMethod：枚舉了HTTP request 幾種方法：GET、HEAD、POST、PUT、PATCH、DELETE、OPTIONS、TRACE。該枚舉類型主要被ClientHttpRequest（package  org.springframework.http）和RestTemplate（package org.springframework.web.client）使用。

        枚舉是Java1.5引入的新特性，經過關鍵字enum來定義枚舉類。枚舉類是一種特殊類，它和普通類同樣可使用構造器、定義成員變量和方法，也能實現一個或多個接口，但枚舉類不能繼承其餘類。

（19）HttpStatus：枚舉了HTTP的狀態碼。經過提供的series()函數能夠獲得該狀態碼屬於哪一大類：INFORMATIONAL（1xx消息）、SUCCESSFUL（2xx成功）、REDIRECTION（3xx重定向）、CLIENT_ERROR（4xx客戶端錯誤）、SERVER_ERROR（5xx服務器錯誤）。

（20）HttpRange：使用Range首部來表示一個HTTP（byte） range。HTTP經過首部Range屬性容許客戶端只請求文檔的一部分，或者說某個範圍。

        GET /bigfile.html HTTP/1.1

        Host: www.joes-hardware.com

        Range: bytes=4000-

        User-Agent: Mozilla/4.61 [en] (WinNT; I)

        ...

        在上例中，客戶端請求的是文檔開頭4000 字節以後的部分（沒必要給出結尾字節數，由於請求方可能不知道文檔的大小）。在客戶端收到了開頭的4000 字節以後就失敗的狀況下，可使用這種形式的範圍請求。

        還能夠用Range 首部來請求多個範圍（這些範圍能夠按任意順序給出，也能夠相互重疊）。例如，假設客戶端同時鏈接到多個服務器，爲了加速下載文檔而從不一樣的服務器下載同一個文檔的不一樣部分。對於客戶端在一個請求內請求多個不一樣範圍的狀況，返回的響應也是單個實體，它有一個多部分主體及Content-Type: multipart/byteranges 首部。Range 首部在流行的點對點（Peer-to-Peer，P2P）文件共享客戶端軟件中獲得普遍應用，它們從不一樣的對等實體同時下載多媒體文件的不一樣部分。

（21）CacheControl：控制緩存的開關，用於標識請求或響應中是否開啓了緩存，使用了哪一種緩存方式。

一、在請求中使用Cache-Control時，可選的值有：

        no-cache：告知（代理）服務器不直接使用緩存，要求向原服務器發起請求。

        no-store：全部內容都不會被保存到緩存或Internet臨時文件中。

        max-age=delta-seconds：告知服務器客戶端但願接收一個存在時間不大於delta-seconds秒的資源。

        max-stale[=delat-seconds] ：告知（代理）服務器客戶端願意接收一個超過緩存時間的資源，如有定義delta-seconds則爲delta-seconds秒，若沒有則爲任意超出時間。

        min-fresh=delta-seconds：告知（代理）服務器客戶端但願接收一個在小於delta-seconds秒內被更新過的資源。

        no-transform：告知（代理）服務器客戶端但願獲取試題數據沒有被轉換（好比壓縮）過的資源。

        only-if-cached：告知（代理）服務器客戶端但願獲取緩存的內容（如有），而不用向服務器發去請求。

        cache-extension：自定義拓展值，若服務器不識別該值將被忽略掉。

二、在響應中使用Cache-Control時，可選的值有：

        public：代表任何狀況下都得緩存該資源（即便是須要HTTP認證的資源）。

        Private[=」field-name」] ：代表返回報文中所有或部分（若指定了field-name則爲field-name的字段數據）僅開放給某些用戶（服務器指定的share-user，如代理服務器）作緩存使用，其餘用戶則不能緩存這些數據。

        no-cache：不直接使用緩存，要求向服務器發起請求。

        no-store：全部內容都不會被保存到緩存或Internet臨時文件中。

        no-transform：告知客戶端緩存文件時不得對實體數據作任何改變。

        only-if-cached：告知（代理）服務器客戶端但願獲取緩存的內容（如有），而不用向原服務器發去請求。

        must-revalidate：當前資源必定是向原服務器發去驗證請求的，若請求失敗會返回504（而非代理服務器上的緩存）

        proxy-revalidate：與must-revalidate相似，但僅能應用於共享緩存（如代理）。

        max-age=delta-seconds：告知客戶端該資源在delta-seconds秒內是新鮮的，無需向服務器發請求。

        s-maxage=delta-seconds：同max-age，但僅應用於共享緩存（如代理）

        cache-extension：自定義拓展值，若服務器不識別該值將被忽略掉。

（22）ContentDisposition：該類表示在RFC 6266中定義的屬性Content-Disposition。Content-Disposition 屬性是做爲對下載文件的一個標識字段，有兩種類型：inline 和 attachment。inline ：將文件內容直接顯示在頁面；attachment：彈出對話框讓用戶下載。RFC 6266正式將Content-Disposition歸入 HTTP 標準。

（23）HttpLogging：若是"org.springframework.web"日誌功能開啓，可是"org.springframework.http"日誌功能沒有開始，那麼此時建立一個共享的日誌記錄器（命名爲org.springframework.web.HttpLogging），用來記錄和HTTP相關的日誌。這也就是說"org.springframework.web"會開啓全部web日誌記錄器，包括一些低層級的包（如"org.springframework.http"）和模塊（好比來自於spring-core被包裝進EncoderHttpMessageWriter或DecoderHttpMessageReader的編解碼器）。

（24）HttpCookie：用來表示一條HTTP cookie，以name-value（名稱-鍵值對）形式表示。

        HTTP協議是無狀態的協議，一旦數據交換完畢，客戶端與服務器端的鏈接就會關閉，再次交換數據須要創建新的鏈接。這就意味着服務器沒法從鏈接上跟蹤會話。Cookie就是這樣的一種機制。它能夠彌補HTTP協議無狀態的不足，是http協議的一個擴展。

        有兩個http頭部是專門負責設置以及發送cookie的,它們分別是Set-Cookie（響應報文首部）以及Cookie（請求報文首部）。當服務器返回給客戶端一個http響應信息時，其中若是包含Set-Cookie這個頭部時，意思就是指示客戶端創建一個cookie，而且在後續的http請求中自動發送這個cookie到服務器端，直到這個cookie過時。若是cookie的生存時間是整個會話期間的話，那麼瀏覽器會將cookie保存在內存中，瀏覽器關閉時就會自動清除這個cookie。另一種狀況就是保存在客戶端的硬盤中，瀏覽器關閉的話，該cookie也不會被清除，下次打開瀏覽器訪問對應網站時，這個cookie就會自動再次發送到服務器端。

（25）ResponseCookie：繼承自HttpCookie，增長了Set-Cookie 響應首部的一些屬性。下面是Set-cookie一個簡單的例子：

        HTTP/1.0 200 OK

        Set-cookie: id="34294"; domain="joes-hardware.com"

        Content-type: text/html

        Content-length: 1903

        最初的cookie 規範是由網景公司定義的。這些「 版本0」 的cookie 定義了Set-Cookie 響應首部、cookie 請求首部以及用於控制cookie 的字段。版本0（網景）的Set-Cookie屬性：

        一、NAME=VALUE：強制的，服務器能夠建立任意的NAME=VALUE關聯，在後續對站點的訪問中會將其送回給服務器。

        二、Expires：可選的，該屬性用來指定一個日期字符串，用來定義cookie的實際生存期。一旦到了過了生存日期，就再也不存儲或者發佈這個cookie了。

        三、Domain：可選的。瀏覽器只向指定域中的服務器發送cookie。

        四、Path：可選的。這個屬性能夠爲服務器上特定的文檔分配cookie。

        五、Secure：可選的。若是包含了這一屬性，就只有在HTTP使用SSL安全鏈接時纔會發送cookie。

 

3、client端的request請求（發送出去的）/response響應（接收到的）

        client端的類主要有三種：

        ClientHttpRequest表示一個客戶端發送的HTTP request請求報文（包括基本實現類及支持Buffering、Streaming、Async、StreamingAsync、BufferingAsync拓展類）。

        ClientHttpResponse表示一個客戶端接收到的HTTP response響應報文。（包括基本實現類和支持Async拓展類）。

        ClientHttpRequestFactory用來建立ClientHttpRequest的工廠（包括基本實現類和支持Async拓展類）。

        上述又分爲基於jkd自帶功能、Apache的HttpClient、OkHttp三、Netty4的實現。使用Apache的HttpClient、OkHttp三、Netty4均可，但這些都須要額外導包，默認狀況下Spring使用的是java.net.HttpURLConnection。

（一）http/client/

接口

（1）ClientHttpRequest：表示一個客戶端的request請求報文。繼承自HttpRequest、 HttpOutputMessage（由於從客戶端看request是發送出去的，因此繼承自HttpOutputMessage。同理，客戶端的ClientHttpResponse是接收到的報文，繼承自HttpInputMessage）。經過ClientHttpRequestFactory工廠的實現類建立。該接口定義了一個函數execute()，函數的返回類型就是ClientHttpResponse。

（2）ClientHttpResponse：表示客戶端接收到的HTTP response響應報文。繼承自HttpInputMessage、Closeable。經過執行ClientHttpRequest的execute()函數得到。

（3）ClientHttpRequestFactory：建立ClientHttpRequest對象的工廠。定義了一個函數createRequest(URI, HttpMethod)，根據URI和HttpMethod建立出一個ClientHttpRequest來發送請求。

（4）ClientHttpRequestInitializer：回調接口，在ClientHttpRequest使用以前先對其初始化。

（5）ClientHttpRequestExecution：表示客戶端HTTP request報文執行（execute）的上下文。主要在ClientHttpRequestInterceptor使用，用來在一個攔截器鏈上調用下一個攔截器，若是到了攔截器末尾，執行request自己。

（6）ClientHttpRequestInterceptor：客戶端的Http request請求攔截器，在Http消息發送到服務器前，該方法被調用，對Http Request報文作些處理，好比加頭，更改請求的URL，受權等等。對於客戶端接收到的ClientHttpResponse也能處理。

 

（7）AsyncClientHttpRequest：繼承自HttpRequest、HttpOutputMessage，表示客戶端一個異步的HTTP request請求，經過工廠類建立。（Spring4.0新增，Spring 5.0中廢棄，使用org.springframework.web.reactive.function.client.ClientRequest替代）

應用層的網絡模型有同步與異步。同步意味當前線程是阻塞的，只有本次請求完成後才能進行下一次請求；異步意味着全部的請求能夠同時塞入緩衝區，不阻塞當前的線程。

（8）AsyncClientHttpRequestFactory：建立AsyncClientHttpRequest的工廠，。經過函數createAsyncRequest(URI, HttpMethod)建立。（Spring4.0新增，Spring 5.0中廢棄，使用org.springframework.http.client.reactive.ClientHttpConnector替代）

（9）AsyncClientHttpRequestExecution：ClientHttpRequestExecution異步拓展。（Spring4.3新增，Spring 5.0中廢棄，使用org.springframework.web.reactive.function.client.ExchangeFilterFunction替代）

（10）AsyncClientHttpRequestInterceptor：ClientHttpRequestInterceptor異步拓展。（Spring4.3新增，Spring 5.0中廢棄，使用org.springframework.web.reactive.function.client.ExchangeFilterFunction替代）

 

抽象類

（11）AbstractClientHttpRequest：實現接口ClientHttpRequest，確保首部和報文體不會屢次寫入。

（12）AbstractBufferingClientHttpRequest：繼承自AbstractClientHttpRequest。在request請求報文發送出去以前，緩存request body，內部private ByteArrayOutputStream bufferedOutput變量保存了request body的內容，避免流的二次讀取會致使讀取不到數據。

（13）AbstractAsyncClientHttpRequest：實現 AsyncClientHttpRequest接口的抽象類。（ Spring 5.0中廢棄，使用org.springframework.http.client.reactive. AbstractClientHttpRequest替代。）

（14）AbstractBufferingAsyncClientHttpRequest：同時拓展了異步和緩存功能的request報文，繼承自AbstractAsyncClientHttpRequest。（Spring 5.0中廢棄，無直接替代者）。

 

（15）AbstractClientHttpResponse：實現接口ClientHttpResponse。

（16）AbstractClientHttpRequestFactoryWrapper：裝飾抽象類，實現接口ClientHttpRequestFactory，裝飾另外一個request factory。裝飾模式建立了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。裝飾類通常是一個抽象類，屬性裏有一個private變量指向ClientHttpRequestFactory，經過構造函數傳遞給被該修飾者，createRequest方法委託給被修飾者執行。

 

類

裝飾器類

（17）BufferingClientHttpRequestWrapper：包裝另一個request。

（28）BufferingClientHttpResponseWrapper：實現ClientHttpResponse接口。考慮到屢次調用getBody()，將接收到的response報文的body部分讀入到內存中。

（19）BufferingClientHttpRequestFactory：ClientHttpRequestFactory的裝飾器，使得具備緩存的能力。若開啓緩存功能（有開關可控），會使用BufferingClientHttpRequestWrapper包裝原來的ClientHttpRequest。這樣發送請求後獲得的是BufferingClientHttpResponseWrapper響應。

 

（20）InterceptingClientHttpRequest：包裝了ClientHttpRequest，支持HTTP 請求攔截器 ClientHttpRequestInterceptor。該類重寫了executeInternal方法，經過內部類InterceptingRequestExecution實現interceptors順序執行。該內部類中的的execute()方法的特色是：若存在攔截器，交給給攔截器去執行發送請求return nextInterceptor.intercept(request, body, this)，不然就本身上。

（21）InterceptingAsyncClientHttpRequest：包裝了AsyncClientHttpRequest，該類重寫了executeInternal方法，經過內部類AsyncRequestExecution實現AsyncClientHttpRequestInterceptor順序執行。該內部類中的的executeAsync()方法的特色是：若存在攔截器，交給給攔截器去執行發送請求：

        return interceptor.intercept(request, body, this);

不然就本身上：

        delegate = requestFactory.createAsyncRequest(uri, method);

        return delegate.executeAsync();

（22）InterceptingClientHttpRequestFactory：繼承自AbstractClientHttpRequestFactoryWrapper。包裝ClientHttpRequestFactory，以支持ClientHttpRequestInterceptor（客戶端的Http request請求攔截器，在Http消息發送到服務器前，該方法被調用，對Http Request報文作些處理）。

（23）InterceptingAsyncClientHttpRequestFactory：實現接口AsyncClientHttpRequestFactory。包裝AsyncClientHttpRequestFactory，以支持AsyncClientHttpRequestInterceptor。（Spring 5.0,廢棄，無代替者）

 

        在介紹下面類以前，先整體介紹下ClientHttpRequest和ClientHttpRequestFactory在不一樣庫下的實現：

        ClientHttpRequest它表明請求的客戶端，該接口繼承自HttpRequest、HttpOutputMessage，只有一個ClientHttpResponse execute() throws IOException方法。其中HttpUrlConnection 、OkHttp三、Netty、HttpComponents對它都有實現。默認狀況下Spring使用的是java.net.HttpURLConnection，也可使用OkHttp三、Netty四、Apache的HttpClient，但這些都須要額外導包。

        ClientHttpRequestFactory是一個函數式接口，用於根據URI和HttpMethod建立出一個ClientHttpRequest來發送請求。根據使用底層http庫的不一樣能夠分爲：

        一、SimpleClientHttpRequestFactory：Spring內置ClientHttpRequestFactory默認的實現，它使用JDK工具(來自java.net包的類)，所以不依賴於第三方庫。

        二、OkHttp3ClientHttpRequestFactory：封裝OkHttp 3.x

        三、Netty4ClientHttpRequestFactory：封裝Netty 4。（Spring 5.0中廢棄，使用org.springframework.http.client.reactive.ReactorClientHttpConnector替代）。

        四、HttpComponentsClientHttpRequestFactory：封裝Apache的HttpClient。

 

使用JDK內置庫

（24）SimpleBufferingClientHttpRequest：ClientHttpRequest接口的實現類，帶緩衝功能。經過SimpleClientHttpRequestFactory建立。

（25）SimpleStreamingClientHttpRequest：ClientHttpRequest接口的實現類，能執行流處理請求，經過SimpleClientHttpRequestFactory建立。

（26）SimpleBufferingAsyncClientHttpRequest：繼承自AbstractBufferingAsyncClientHttpRequest，經過SimpleClientHttpRequestFactory建立。

（27）SimpleStreamingAsyncClientHttpRequest：繼承自AbstractAsyncClientHttpRequest，能執行流處理請求，經過SimpleClientHttpRequestFactory建立。

（28）SimpleClientHttpResponse：ClientHttpResponse接口實現類，經過執行SimpleBufferingClientHttpRequest的函數execute()或者SimpleStreamingClientHttpRequest的函數execute()得到。

（29）SimpleClientHttpRequestFactory：ClientHttpRequestFactory接口的實現類，繼承自ClientHttpRequestFactory和AsyncClientHttpRequestFactory。重寫了ClientHttpRequestFactory的createRequest()函數（用來生成上面2四、25兩種類型的request）和AsyncClientHttpRequestFactory的createAsyncRequest()函數（用來生成上面2六、27兩種類型的request）。

 

使用OkHttp 3.x框架

        OkHttp是一款優秀的HTTP框架，一個處理網絡請求的開源項目，是安卓端的輕量級框架，由移動支付Square公司貢獻。支持get請求和post請求，支持基於Http的文件上傳和下載，支持加載圖片，支持下載文件透明的GZIP壓縮，支持響應緩存避免重複的網絡請求，支持使用鏈接池來下降響應延遲問題。導包示例：

        <dependency>

            <groupId>com.squareup.okhttp3</groupId>

            <artifactId>okhttp</artifactId>

            <version>3.14.0</version>

        </dependency>

（30）OkHttp3ClientHttpRequest：基於OkHttp 3.x的ClientHttpRequest接口的實現類。經過OkHttp3ClientHttpRequestFactory建立。

（31）OkHttp3AsyncClientHttpRequest：基於OkHttp 3.x的AsyncClientHttpRequest接口的實現類。經過OkHttp3ClientHttpRequestFactory建立。（Spring 5.0中廢棄，無替代者）。

（32）OkHttp3ClientHttpResponse：基於OkHttp 3.x的ClientHttpResponse接口實現類。經過執行OkHttp3ClientHttpRequest的executeInternal()函數得到。

（33）OkHttp3ClientHttpRequestFactory：ClientHttpRequestFactory接口的實現類，基於OkHttp 3.x建立request，createRequest()函數建立OkHttp3ClientHttpRequest；createAsyncRequest()函數建立OkHttp3AsyncClientHttpRequest。

 

使用Netty 4框架

        Netty是由JBOSS提供給的一個java開源框架。Netty提供異步的、事件驅動的網絡應用框架和工具，用以快速開發高性能、高可靠的網絡服務器和客戶端程序。導包示例：

        <dependency>

            <groupId>io.netty</groupId>

            <artifactId>netty-all</artifactId>

            <version>5.0.0.Alpha2</version>

        </dependency>

（34）Netty4ClientHttpRequest：基於Netty 4的ClientHttpRequest接口的實現類，經過Netty4ClientHttpRequestFactory建立。

（35）Netty4ClientHttpResponse：基於Netty 4的ClientHttpResponse接口的實現類。

（36）Netty4ClientHttpRequestFactory ：ClientHttpRequestFactory接口的實現類，基於Netty 4建立Netty4ClientHttpRequest。

 

使用Apache的HttpClient框架

        Apache開源組織的HttpComponents 也就是之前的httpclient項目，能夠用來提供高效的、最新的、功能豐富的支持 HTTP 協議的客戶端/服務器編程工具包，支持 HTTP 協議最新的版本和建議。如今的 HttpComponents 包含多個子項目：HttpComponents Core、HttpComponents Client、HttpComponents AsyncClient、Commons HttpClient。導包示例：

        <dependency>

            <groupId>org.apache.httpcomponents</groupId>

            <artifactId>httpclient</artifactId>

            <version>4.5.10</version>

        </dependency>

（37）HttpComponentsClientHttpRequest：基於Apache HttpComponents HttpClient的ClientHttpRequest接口的實現類。經過（42）HttpComponentsClientHttpRequestFactory建立。

（38）HttpComponentsStreamingClientHttpRequest：基於Apache HttpComponents HttpClient的執行流處理請求的ClientHttpRequest接口的實現類。經過（42）HttpComponentsClientHttpRequestFactory建立。

（39）HttpComponentsAsyncClientHttpRequest：基於Apache HttpComponents HttpAsyncClient的ClientHttpRequest接口的實現類，經過（43）HttpComponentsAsyncClientHttpRequestFactory建立。（Spring 5.0中廢棄，無替代者）

（40）HttpComponentsClientHttpResponse：基於Apache HttpComponents HttpClient的ClientHttpResponse接口的實現類。經過（37）HttpComponentsClientHttpRequest的executeInternal()函數建立。

（41）HttpComponentsAsyncClientHttpResponse：基於Apache HttpComponents HttpAsyncClient的ClientHttpResponse接口的實現類。經過（39）HttpComponentsAsyncClientHttpRequest建立。（Spring 5.0中廢棄，無替代者）

（42）HttpComponentsClientHttpRequestFactory：ClientHttpRequestFactory接口的實現類，基於Apache HttpComponents HttpClient建立request。經過createRequest()函數來建立（37）HttpComponentsClientHttpRequest（bufferRequestBody屬性爲true狀況下，屬性bufferRequestBody用來表示該工廠是否須要在內部緩存request body，默認爲true）或者（38）HttpComponentsStreamingClientHttpRequest（bufferRequestBody屬性爲false狀況下，若是經過POST或者PUT方法發送大量的數據，推薦設置爲false，以防止緩存溢出）。

（43）HttpComponentsAsyncClientHttpRequestFactory：繼承自HttpComponentsClientHttpRequestFactory，基於Apache HttpComponents HttpAsyncClient 4.0建立（39）HttpComponentsAsyncClientHttpRequest（Spring 5.0中廢棄，無替代者）

 

（44）MultipartBodyBuilder：爲multipart請求類準備請求體，以MultiValueMap<String, HttpEntity>形式返回。http協議採納了多部對象集合（multipart)，multipart 請求類主要是對文件上傳進行的處理，發送一份報文主體內可含有多個類型實體，一般在圖片或者文本上傳時使用，其中郵件上傳各類附件的機制也是用了MIME的Mulipart方法。

（二）http/client/reactive

        reactive programming（響應式編程）是一種異步編程風格，它關注數據流和變化的傳播，與之相對應的是imperative programming（命令式編程）。

        在命令式編程中，a:=b+c意味着將b+c的結果賦值給a，而且此後b或c的值發生變化不會影響到a的值。而在響應式編程中，a的值會隨着b或c的改變而自動更新，而且不須要從新執行a:=b+c來肯定當前分配給a的值。例如，在 model–view–controller (MVC) 架構中，響應式編程能夠促進基礎模型中的更改，這些更改會自動反映在關聯的視圖中。

        若是從推拉的角度來看的話，響應式編程是「推」，它主動將變化推送給它的訂閱者。Publisher-Subscriber是兩個很是重要的概念。本質來說，響應式編程上是對數據流或某種變化所做出的反應，可是這個變化何時發生是未知的，因此他是一種基於異步、回調的方式在處理問題

 

接口

（1）ClientHttpRequest：繼承自ReactiveHttpOutputMessage的接口，表示一個客戶端的響應式HTTP request請求報文。

（2）ClientHttpResponse：繼承自ReactiveHttpInputMessage的接口，表示一個客戶端的響應式HTTP response響應報文。

（3）ClientHttpConnector：客戶端的HTTP鏈接器接口，從HTTP客戶端抽象出來的一個功能，使HTTP客戶端鏈接到服務器上，也提供了發送ClientHttpRequest和接收ClientHttpResponse全部必要的基礎設施。

抽象類

（4）AbstractClientHttpRequest：上述ClientHttpRequest接口實現的抽象類。

類

裝飾器類

（5）ClientHttpRequestDecorator：ClientHttpRequest的裝飾器。

（6）ClientHttpResponseDecorator：ClientHttpResponse的裝飾器。

 

Jetty ReactiveStreams HTTP client

Jetty 是一個開源的servlet容器，適用於一個通用的Reactive Streams API。

（7）JettyClientHttpRequest：繼承自AbstractClientHttpRequest。

（8）JettyClientHttpResponse：ClientHttpResponse接口實現類。

（9）JettyClientHttpConnector：ClientHttpConnector接口實現類。

（10）JettyResourceFactory：在Spring的ApplicationContext容器生命週期範圍內，用來管理Jetty資源的工廠，好比Executor、ByteBufferPool、Scheduler。該工廠實現了InitializingBean、DisposableBean接口。通常被聲明爲Spring管理bean。

 

Reactor-Netty HTTP client

        Netty是一個java開源框架，適用於一個通用的Reactive Streams API。

（11）ReactorClientHttpRequest：繼承自AbstractClientHttpRequest、ZeroCopyHttpOutputMessage。

（12）ReactorClientHttpResponse：ClientHttpResponse接口實現類。

（13）ReactorClientHttpConnector：ClientHttpConnector接口實現類。

（14）ReactorResourceFactory：在Spring的ApplicationContext容器生命週期範圍內，用來管理Reactor Netty資源的工廠，好比LoopResources、ConnectionProvider。該工廠實現了InitializingBean、DisposableBean接口。通常被聲明爲Spring管理bean。

（三）http/client/support

（1）HttpAccessor：做爲RestTemplate的基類或者其餘HTTP訪問網關的助手類。定義了一些通用的屬性，如ClientHttpRequestFactory。

（2）AsyncHttpAccessor：做爲AsyncRestTemplate的基類或者其餘HTTP訪問網關的助手類。定義了一些通用的屬性，如AsyncClientHttpRequestFactory。

（3）InterceptingHttpAccessor：繼承自HttpAccessor，增長了一些攔截器相關的屬性。

（4）InterceptingAsyncHttpAccessor：繼承自AsyncHttpAccessor，增長了請求攔截功能。

 

（5）BasicAuthenticationInterceptor：ClientHttpRequestInterceptor接口的實現類，使用username/password作一個HTTP基本認證，除非的Authorization header設置好了。

（6）BasicAuthorizationInterceptor：ClientHttpRequestInterceptor接口的實現類，使用一個基本的 Authorization 消息頭。

 

（7）HttpRequestWrapper：HttpRequest裝飾器類。

（8）ProxyFactoryBean：實現ProxyFactoryBean、InitializingBean接口，用於生成代理對象java.net.Proxy。重寫了InitializingBean的afterPropertiesSet函數，這個方法在全部的屬性被初始化後可是在init前調用。

 

4、server端的request請求（接收到的）/response響應（發送出去的）

（一）http/server/

（1）PathContainer：接口，將經過執行函數parsePath(String)獲得的URI path結構化表示成一系列的分隔符和PathSegment。

（2）DefaultPathContainer：PathContainer接口的默認實現。

（3）RequestPath：繼承自PathContainer的接口，表示一個請求報文完整的路徑。

（4）DefaultRequestPath：RequestPath接口的默認實現。

 

（5）ServerHttpRequest：繼承自HttpRequest、HttpInputMessage的接口，表示服務器端接收到的HTTP request請求報文。

（6）ServerHttpResponse：繼承自HttpOutputMessage、Flushable、Closeable的接口，表示服務器端發送出去的HTTP response響應報文。

（7）ServerHttpAsyncRequestControl：一個控件接口，能將對HTTP request請求報文的處理置於異步模式下，在response響應處於open的狀態下直至明確關閉。

 

（8）ServletServerHttpRequest：基於HttpServletRequest的ServerHttpRequest接口的實現類。

        HttpServletRequest（javax.servlet.http.HttpServletRequest）繼承自ServletRequest，表明客戶端的請求，當客戶端經過HTTP協議訪問服務器時，HTTP請求頭中的全部信息都封裝在這個對象中，包含了客戶端請求信息包括請求的地址，請求的參數，提交的數據，上傳的文件客戶端的ip甚至客戶端操做系統都包含在其內。經過這個對象提供的方法，能夠得到客戶端請求的全部信息。

（9）ServletServerHttpResponse：基於HttpServletResponse的ServerHttpResponse接口的實現類。

        HttpServletResponse繼承了ServletResponse接口，表明服務器的響應。這個對象中封裝了向客戶端發送數據、發送響應頭，發送響應狀態碼的方法。並提供了與Http協議有關的方法，這些方法的主要功能是設置HTTP狀態碼和管理Cookie。

（10）ServletServerHttpAsyncRequestControl：實現了接口AsyncListener、ServerHttpAsyncRequestControl，在Servlet容器(Servlet 3.0+)上使用。

（二）http/server/reactive

（1）AbstractListenerReadPublisher：實現接口Publisher的抽象類，用來在event-listener read APIs 和Reactive Streams創建聯繫。具體來講就是使用Servlet 3.1 non-blocking I/O和Undertow XNIO讀取HTTP request請求體，此外也可使用標準的Java WebSocket (JSR-356)、Jetty、Undertow處理剛收到的WebSocket消息。

（2）AbstractListenerServerHttpResponse：抽象類，做爲基於listener的服務器端響應報文 的父類，好比Servlet 3.1和Undertow。

 

（3）AbstractListenerWriteProcessor：實現Processor接口的抽象類，用來在event-listener write APIs 和Reactive Streams創建聯繫。具體來講就是使用Servlet 3.1 non-blocking I/O和Undertow XNIO寫入HTTP request請求體，此外也可使用標準的Java WebSocket (JSR-356)、Jetty、Undertow寫入WebSocket消息。

（4）AbstractListenerWriteFlushProcessor：實現Processor接口的抽象類，AbstractListenerWriteProcessor的一個替代類，不一樣的是在每個嵌套Publisher都完成後，writing a Publisher with flush boundaries enforces。

 

（5）ChannelSendOperator：考慮一個用source Publisher寫的寫函數，返回的結果是一個result Pulisher，這個操做符的做用就是推遲這個寫函數的調用，直到咱們肯定source Publisher將會無錯誤的發佈。

（6）DefaultServerHttpRequestBuilder：ServerHttpRequest.Builder接口的默認實現類。

（7）WriteResultPublisher：實現Publisher接口，該發佈者經過執行ServerHttpResponse的writeWith(Publisher)函數獲得。

        Publisher是一個能夠提供 0-N 個序列元素的提供者，並根據其訂閱者Subscriber的需求推送元素。一個Publisher能夠支持多個訂閱者，並能夠根據訂閱者的邏輯進行推送序列元素。Reactor中有兩種Publisher：Flux和Mono，其中Flux用來表示0-N個元素的異步序列，Mono用來表示0-1個元素的異步序列。

        一、Flux 是一個發出(emit)0-N個元素組成的異步序列的Publisher<T>,能夠被onComplete信號或者onError信號所終止。在響應流規範中存在三種給下游消費者調用的方法 onNext、onComplete和onError。

        二、Mono 是一個發出(emit)0-1個元素的Publisher<T>，能夠被onComplete信號或者onError信號所終止。

（8）SslInfo：SSL 會話信息的句柄。SSL(Secure Sockets Layer 安全套接字協議)是爲網絡通訊提供安全及數據完整性的一種安全協議。

（9）DefaultSslInfo：SslInfo接口的默認實現。

 

（10）JettyHeadersAdapter：實現MultiValueMap接口，用於包裝Jetty HTTP headers。

        MultiValueMap即一個鍵對應多個值，咱們平時使用的Map一個key只能對應一個value，若是想要一個key對應多個value，一般咱們會將多個value放到一個集合中。sping對此作了簡單的封裝，封裝以後的接口爲MultiValueMap。

Netty、Undertow、Tomcat、Jetty都是web容器，都適用於一個通用的Reactive Streams API。

（11）NettyHeadersAdapter：實現MultiValueMap接口，用於包裝Netty HTTP headers。

（12）TomcatHeadersAdapter：實現MultiValueMap接口，用於包裝Tomcat HTTP headers。

（13）UndertowHeadersAdapter：實現MultiValueMap接口，用於包裝Jetty HTTP headers。

 

（14）HttpHandler：一個對於HTTP請求的略偏底層的協定， 規範了Tomcat、Jetty、Netty、Undertow、Servlet3.1等服務器。 旨在對於不一樣的Web服務器提供更加抽象統一的接口。更高一級的通用模塊，如WebFilter、WebSession、ServerWebExchange在org.springframework.web.server包中。應用級別編程模型，如註解控制器和功能處理程序在spring-webflux模塊中。

（15）ContextPathCompositeHandler：HttpHandler接口實現類。

（16）ReactorHttpHandlerAdapter：適配器，適配HttpHandler和處理Netty channel響應式函數。實現了接口BiFunction<HttpServerRequest, HttpServerResponse, Mono<Void>>，HttpServerRequest表示函數的第一個參數的類型，HttpServerResponse表示函數的第二個參數的類型，Mono<Void>表示函數結果的類型。方法apply​(reactorRequest, reactorResponse)將此函數應用於給定的參數。

 

（17）ServletHttpHandlerAdapter：適配器，適配HttpHandler和HttpServlet

（18）TomcatHttpHandlerAdapter：繼承自ServletHttpHandlerAdapter，對ServletHttpHandlerAdapter適配器作了拓展，使用Tomcat APIs讀取接收到的request請求報文或者寫入要發送出去的response響應報文。

（19）JettyHttpHandlerAdapter：繼承自ServletHttpHandlerAdapter，對ServletHttpHandlerAdapter適配器作了拓展，使用Jetty APIs寫入要發送出去的response響應報文。

（20）UndertowHttpHandlerAdapter：實現接口io.undertow.server.HttpHandler，適配HttpHandler和io.undertow.server.HttpHandler。

 

（21）ServerHttpRequest：繼承自HttpRequest，ReactiveHttpInputMessage的接口。表示一個響應式的服務器端接收到的HTTP request請求報文。

（22）ServerHttpResponse：繼承自ReactiveHttpOutputMessage的接口。表示一個響應式的服務器端發送出去的HTTP response響應報文。

 

（23）AbstractServerHttpRequest：ServerHttpRequest接口實現的抽象類。

（24）AbstractServerHttpResponse：ServerHttpResponse接口實現的抽象類。

 

（25）ServerHttpRequestDecorator：ServerHttpRequest裝飾類。

（26）ServerHttpResponseDecorator：ServerHttpResponse裝飾類。

（27）HttpHeadResponseDecorator：繼承自ServerHttpResponseDecorator，HTTP request使用head方法的請求報文（HEAD方法請求一個與GET請求的響應相同的響應，但沒有響應體）返回的響應報文ServerHttpResponse的裝飾類。

 

（28）ServletServerHttpRequest：Servlet服務器端收到的請求報文。

（29）ServletServerHttpResponse：Servlet服務器端發送出去的響應報文。

 

（30）ReactorServerHttpRequest：Reactor服務器端收到的請求報文。

（31）ReactorServerHttpResponse：Reactor服務器端發送出去的響應報文。

 

（32）UndertowServerHttpRequest：Undertow服務器端收到的請求報文。

（33）UndertowServerHttpResponse：Undertow服務器端發送出去的響應報文。

 

5、格式的轉換，如json，rss，xml等

（一）http/converter/

（1）HttpMessageConverter：策略接口， HTTP request 請求報文和response響應報文的轉換器，將請求信息轉換爲一個對象(類型爲T)，將對象(類型爲T)輸出爲響應信息。該接口有5個方法：獲取該轉換器支持的 MediaType列表（getSupportedMediaTypes），判斷接收到request是否能讀（canRead），判斷可否寫發送出去的報文（canWrite），讀取接收到的報文（read），寫入要發送的報文（write）。

（2）AbstractHttpMessageConverter：大部分HttpMessageConverter接口實現類的抽象基類。經過setSupportedMediaTypes(List)函數能夠設置支持的MediaTypes，在寫入要發送出去的消息時增長了對Content-Type和Content-Length支持。

（3）GenericHttpMessageConverter：繼承自HttpMessageConverter的接口，用來將一個HTTP request報文轉換成指定通用類型的目標對象，或者將一個指定通用類型的源對象轉換成一個HTTP response報文。

（4）AbstractGenericHttpMessageConverter：大部分GenericHttpMessageConverter接口實現類的抽象基類。

 

（5）ByteArrayHttpMessageConverter：將request信息轉換爲byte數組，或者將byte數組輸出爲response信息。

（6）StringHttpMessageConverter：將request信息轉換爲String類型，或者將String類型輸出爲response信息。

（7）ObjectToStringHttpMessageConverter：使用StringHttpMessageConverter對content進行讀寫，使用ConversionService對String content和目標對象進行相互轉換。

（8）FormHttpMessageConverter：將request信息轉換爲HTML表單，或者將HTML表單輸出爲response信息，或者將MultiValueMap<String, String>輸出爲response信息（可是不會將request信息轉換成MultiValueMap）。

（9）BufferedImageHttpMessageConverter：將request信息轉換爲BufferedImage，或者將BufferedImage輸出爲response信息。

（10）ResourceHttpMessageConverter：將request信息轉換爲Resources，或者將Resources輸出爲response信息。默認狀況下，該轉換器能夠讀取全部類型的media（讀取request），能輸出到response中的類型在MediaTypeFactory定義。

（11）ResourceRegionHttpMessageConverter：將一個或者一批ResourceRegion輸出爲response信息。

（二）http/converter/cbor

MappingJackson2CborHttpMessageConverter：能使用專用的Jackson 2.x拓展庫對CBOR格式的數據進行讀寫。簡明二進制對象展示（CBOR，Concise Binary Object Representation）是一種提供良好壓縮性，擴展性強，不須要進行版本協商的二進制數據交換形式。

（三）http/converter/feed

（1）AbstractWireFeedHttpMessageConverter：做爲AtomFeedHttpMessageConverter和RssChannelHttpMessageConverter的基類，使用了Rome開源包。

Feed：消息來源，是一種資料格式，網站經過它將最新資訊傳播給用戶。將feed匯流於一處稱爲聚合。RSS是站點用來和其餘站點之間共享內容的一種簡易方式（也叫聚合內容），一般被用於新聞和其餘按順序排列的網站，例如Blog。ATOM是Rss的一個替代品。RSS和ATOM兩種訂閱方式出形式都是FEED。Rome是爲RSS聚合而開發的開源包。

（2）AtomFeedHttpMessageConverter：轉換Atom feeds。

（3）RssChannelHttpMessageConverter：轉換RSS feeds。

（四）http/converter/json

        json (JavaScript Object Notation) 是javascript對象的一種形態，一種輕量級的數據交換格式，易於人閱讀和編寫，同時也易於機器解析和生成，普遍應用於各類數據的交互中，尤爲是服務器與客戶端的交互。

        json有兩種數據類型：json和jsonb，而二者惟一的區別在於效率，json是對輸入的完整拷貝，使用時再去解析，因此它會保留輸入的空格，重複鍵以及順序等。而jsonb是解析輸入後保存的二進制，它在解析時會刪除沒必要要的空格和重複的鍵，順序和輸入可能也不相同。使用時不用再次解析。二者對重複鍵的處理都是保留最後一個鍵值對。效率的差異：json類型存儲快，使用慢，jsonb類型存儲稍慢，使用較快。

        Java操做json的庫有：JSON-B 、Jackson、Gson和fastjson。

        Java EE8 中新的 JSON Binding API (JSON-B) 支持在 Java 對象與JSON之間序列化和反序列化。從功能上講，JSON-B API包含兩個入口點接口：javax.json.bind.Jsonb和javax.json.bindJsonBuilder。Jsonb接口分別經過方法toJson()和fromJson()實現序列化和反序列化。JsonBuilder接口基於一組可選的操做而構造Jsonb實例，併爲客戶端提供對實例的訪問權。

        Jackson 是一個 Java 的用來處理 JSON 格式數據的類庫。

        Fastjson 是一個 Java 庫，能夠將 Java 對象轉換爲 JSON 格式，固然它也能夠將 JSON 字符串轉換爲 Java 對象。

        Gson（又稱Google Gson）是Google公司發佈的一個開放源代碼的Java庫，主要用途爲序列化Java對象爲JSON字符串，或反序列化JSON字符串成Java對象。使用以下例所示：

public class User{
   //省略帶參構造方法
  private int id;
  private String userName;
}
User user = new User(1,"zs");
String userJson = gson.toJson(user);  // 序列化user對象爲 {"id":1,"userName":"zs"}
user = gson.fromJson(userJson,User.class);  //反序列化

（1）AbstractJsonHttpMessageConverter：JSON轉換器的基類，好比GSON和JSON-B。

 

（2）JsonbHttpMessageConverter：使用JSON-B庫的JSON轉換器。

 

（3）MappingJacksonValue：MappingJackson2HttpMessageConverter要執行序列化操做（將Java對象序列化爲JSON字符串）的簡單Java對象。

（4）MappingJacksonInputMessage：此message用來存儲一個Jsonb實例，該message會被進行反序列化成Java對象。

（5）Jackson2ObjectMapperBuilder：構建器，使用流式 API接口來建立ObjectMapper實例。ObjectMapper類是Jackson庫的主要類。ObjectMapper類的readValue API 能夠解析或反序列化json內容爲java對象。 反之，writeValue API能夠序列化任何java對象爲json字符串。

（6）Jackson2ObjectMapperFactoryBean：一個FactoryBean，用來建立Jackson 2.x ObjectMapper對象（默認狀況下），或者XmlMapper對象（createXmlMapper屬性設置爲true狀況下）。

（7）SpringHandlerInstantiator：經過Spring 的ApplicationContext容器建立Jackson自動裝配的JsonSerializer、JsonDeserializer、KeyDeserializer、TypeResolverBuilder、TypeIdResolver的beans。

（8）AbstractJackson2HttpMessageConverter：基於Jackson、與Content-Type無關的HttpMessageConverter接口實現類的抽象基類。

（9）MappingJackson2HttpMessageConverter：HttpMessageConverter接口的實現類，使用Jackson 2.x的ObjectMapper對JSON進行轉換。

 

（10）GsonFactoryBean：FactoryBean，用來建立一個Google Gson 2.x Gson實例。

（11）GsonBuilderUtils：取得Google Gson 2.x  GsonBuilder功能類。GsonBuilder用來生成Gson對象，規定Gson的序列化和返序列化時的格式等內容。

（12）GsonHttpMessageConverter：HttpMessageConverter接口實現類，使用Google Gson庫來對JSON進行轉換。

（五）http/converter/protobuf

（1）ExtensionRegistryInitializer：Google協議消息可以包含能夠被解析的消息拓展，若是相應的配置信息在ExtensionRegistry中已經被註冊過。該接口使用協議消息拓展來初始化ExtensionRegistry

（2）ProtobufHttpMessageConverter：使用Google Protocol Buffers來對com.google.protobuf.Messages進行轉換。

（3）ProtobufJsonFormatHttpMessageConverter：ProtobufHttpMessageConverter的子類，使用Protobuf 3和它的官方庫在對JSON處理上作了加強。Protobuf是google開發的一種跨語言和平臺的序列化數據結構的方式，相似於XML可是更小更快並且更簡單，只須要定義一次結構體，經過生成的源代碼能夠在不一樣的數據流和不一樣的語言平臺上去讀寫數據結構。最新的protobuf3支持更多的語言使用，好比go、object-c等。

（六）http/converter/smile

MappingJackson2SmileHttpMessageConverter：使用Jackson 2.x專用的拓展對Smile數據格式（binary JSON）進行轉換。

        BSON（binary json）是10gen開發的一個數據格式，目前主要用於MongoDB中，是MongoDB的數據存儲格式。BSON基於JSON格式，普通JSON標記和BSON之間的主要區別在於BSON是JSON的二進制標記版本。因爲BSON更緊湊，所以在反序列化時它具備更少的開銷，而且對於大型和複雜的有效載荷來講是更好的選擇。

（七）http/converter/support

AllEncompassingFormHttpMessageConverter：FormHttpMessageConverter轉換器的拓展，增長了對XML和JSON-based parts的支持。

（八）http/converter/xml

（1）AbstractXmlHttpMessageConverter：用來轉換XML的轉換器的抽象基類。繼承該抽象類的轉換器支持text/xml、application/xml、application/*-xml。

（2）AbstractJaxb2HttpMessageConverter：使用JAXB2的轉換器的抽象基類。getJaxbContext()函數用來爲指定的類建立JAXBContext。

        JAXB（Java Architecture for XML Binding) 是一個業界的標準，是一項能夠根據XML Schema產生Java類的技術。該過程當中，JAXB也提供了將XML實例文檔反向生成Java對象樹的方法，並能將Java對象樹的內容從新寫到 XML實例文檔。Jaxb 2.0是JDK 1.6的組成部分，不須要下載第三方jar包便可作到輕鬆轉換。

        JAXBContext 類提供到 JAXB API 的客戶端入口點。它提供了管理實現 JAXB 綁定框架操做所需的 XML/Java 綁定信息的抽象，這些操做包括：解組、編組和驗證。

 

（3）SourceHttpMessageConverter：用來轉換Source對象。

（4）Jaxb2CollectionHttpMessageConverter：該轉換器使用JAXB2來將一個HTTP request報文轉換成XML collections，可是不支持將其轉換成一個HTTP response報文。

（5）Jaxb2RootElementHttpMessageConverter：使用JAXB2來轉換XML（支持讀寫，也就是支持將request轉換成XML，將XML轉換成response報文）

（6）MappingJackson2XmlHttpMessageConverter：使用Jackson 2.x拓展部件來轉換XML，該轉換器支持application/xml、text/xml、application/*+xml，使用UTF-8編碼方式。

（7）MarshallingHttpMessageConverter：使用Spring的Marshaller和Unmarshaller來轉換XML，在轉換器使用以前要先準備好Marshaller和Unmarshaller。

 

6、編/解碼器

        對於表單數據，二進制/文件內容，服務器發送的事件等spring-web模塊提供了包括Jackson JSON，Jackson Smile，JAXB2，Protocol Buffers的編/解碼器以及只支持web的HTTP消息讀/寫器實現。

（一）http/codec/

（1）CodecConfigurer：用來配置和自定義客戶端或者服務器端處理HTTP報文的編解碼器的通用接口。

（2）CodecConfigurerFactory：建立CodecConfigurer的工廠類。

（3）ClientCodecConfigurer：拓展自CodecConfigurer的接口，用於配置和自定義要在客戶端使用的編解碼器。

（4）ServerCodecConfigurer：拓展自CodecConfigurer的接口，用於配置和自定義要在服務器端使用的編解碼器。

（5）LoggingCodecSupport：Encoder、Decoder、HttpMessageReader、HttpMessageWriter類的基類，使用一個日誌記錄器，記錄一些敏感的信息。

 

（6）HttpMessageDecoder：用於解碼分離開的HTTP內容。拓展自Decoder的接口，增長了一些解碼HTTP request 和response body相關的函數。

（7）HttpMessageEncoder：用於編碼分離開的HTTP內容。拓展自Encoder的接口，增長了一些編碼HTTP request 和response body相關的函數。

 

（8）HttpMessageReader：接口，用於解碼HTTP 消息內容的解碼器。

（9）HttpMessageWriter：接口，用於編碼HTTP 消息內容的編碼器。

 

（10）DecoderHttpMessageReader：封裝解碼器HttpMessageReader，使其能夠合適的用於Web應用。

（11）EncoderHttpMessageWriter：封裝編碼器HttpMessageWriter，使其能夠合適的用於Web應用。

 

（12）FormHttpMessageReader：解碼HTML表單數據的解碼器，好比request請求體中"application/x-www-form-urlencoded"類型的內容。

（13）FormHttpMessageWriter：編碼MultiValueMap<String, String>成爲HTML表單數據，如"application/x-www-form-urlencoded"，到request請求體中。

（14）ResourceHttpMessageReader：解碼Resource

（15）ResourceHttpMessageWriter：編碼Resource。

（16）ServerSentEvent：表示一個使用Spring reactive web框架支持的服務器發送事件。服務器向瀏覽器推送信息，除了 WebSocket，還有就是Server-Sent Events。

（17）ServerSentEventHttpMessageReader：解碼器，支持一連串的服務器發送事件、簡單對象。

（18）ServerSentEventHttpMessageWriter："text/event-stream" responses的編碼器。

（二）http/codec/support

（1）BaseCodecConfigurer：實現CodecConfigurer接口的抽象類。

（2）BaseDefaultCodecs：CodecConfigurer.DefaultCodecs接口的默認實現。配置和自定義HTTP報文的默認的編解碼器。

（3）DefaultClientCodecConfigurer：ClientCodecConfigurer接口的默認實現。

（4）DefaultServerCodecConfigurer：ServerCodecConfigurer接口的默認實現。

（5）ClientDefaultCodecsImpl：ClientCodecConfigurer.ClientDefaultCodecs接口的默認實現。

（6）ServerDefaultCodecsImpl：ServerCodecConfigurer.ServerDefaultCodecs接口的默認實現。

（三）http/codec/json

（1）Jackson2CodecSupport：提供支持Jackson 2.9編解碼的方法的抽象基類。

（2）Jackson2Tokenizer：將一個任意大小、字節數組塊的JSON stream轉換成Flux<TokenBuffer>，其中每個token buffer都是一個結構良好的JSON對象。

（3）AbstractJackson2Decoder：Jackson 2.9解碼器的抽象基類。

（4）AbstractJackson2Encoder：爲Jackson 2.9編碼器提供了一些支持性方法的基類。

（5）Jackson2JsonDecoder：將字節流解碼爲JSON並使用Jackson 2.9轉換爲Object。

（6）Jackson2JsonEncoder：使用Jackson 2.9編碼Json。

（7）Jackson2SmileDecoder：使用Jackson 2.9解碼Smile。

（8）Jackson2SmileEncoder：使用Jackson 2.9編碼Smile。

（四）http/codec/cbor

（1）Jackson2CborDecoder：使用Jackson解碼Cbor。

（2）Jackson2CborEncoder：使用Jackson編碼Cbor。

（五）http/codec/multipart

（1）Part：表示"multipart/form-data"數據的一個部分。

（2）FilePart：專指一個multipart request的上傳文件部分。

（3）FormFieldPart：專指表單字段。

（4）MultipartHttpMessageReader：提供對於"multipart/form-data"類型的數據的解碼支持。

（5）MultipartHttpMessageWriter：提供對於"multipart/form-data"類型的數據的編碼支持。

（6）SynchronossPartHttpMessageReader：使用Synchronoss NIO Multipart庫解碼"multipart/form-data"類型的數據。

（六）http/codec/protobuf

（1）ProtobufCodecSupport：提供了Protobuf編解碼一些支持性方法。

（2）ProtobufDecoder：使用Google Protocol Buffers來解碼com.google.protobuf.Message的解碼器。

（3）ProtobufEncoder：使用Google Protocol Buffers來編碼com.google.protobuf.Message的編碼器。

（4）ProtobufHttpMessageWriter：HttpMessageWriter接口的實現類，用於編碼protobuf消息。

（七）http/codec/xml

（1）JaxbContextContainer：JAXBContext實例的句柄。JAXBContext 類提供到 JAXB API 的客戶端入口點。它提供了管理實現 JAXB 綁定框架操做所需的 XML/Java 綁定信息的抽象，這些操做包括：解組、編組和驗證。

（2）XmlEventDecoder：繼承自AbstractDecoder，將一個DataBuffer流解碼成一連串的XMLEvents。

（3）Jaxb2XmlDecoder：繼承自AbstractDecoder，將包含XML元素的字節流解碼成一連串的POJO。

（4）Jaxb2XmlEncoder：將一個單獨的value值編碼成包含XML元素的字節流。

 

本文參考了博客園、CSDN部分文獻。

拓展閱讀：

        Spring框架之beans源碼徹底解析（https://www.cnblogs.com/xxkj/p/13929565.html）

        Spring框架之AOP源碼徹底解析（https://www.cnblogs.com/xxkj/p/14094203.html）

        Spring框架之jms源碼徹底解析（https://www.cnblogs.com/xxkj/p/14137694.html）

 

博衆家之所長，集羣英之薈萃。遴選各IT領域精品雄文！

歡迎關注「IT架構精選」