引言

自從我教授第一堂 Core Spring 課程以來，已將近 10 年。那時幾乎所有內容都是 XML，配置 JPA 或 Spring Security 等可能需要大量艱苦的工作。與此同時，Spring 已經成熟了很多，透過元件掃描、Java 配置和 Spring Boot，使用起來更加有趣。而且 Spring 專案的數量也大大增加了。

Pivotal 培訓繼續加強我們的 Spring 課程並引入新課程——包括 Spring Boot Developer 和 Spring Cloud Services。我已經提供了這些的概述……

此部落格已更新——請參閱此處。

更多資訊

有關更多資訊並檢視我們的應用程式框架、雲原生和大資料套件課程的完整產品組合，請訪問 Pivotal Academy。

引言

注意：2019 年 7 月修訂

使用 Spring、Spring Boot 和 Spring Cloud 設定微服務系統的簡單示例。

微服務允許大型系統由許多協作元件構建。它在程序級別實現了 Spring 在元件級別一直做的事情：鬆散耦合的程序而不是鬆散耦合的元件。

例如，想象一個線上商店，其中包含用於使用者帳戶、產品目錄訂單處理和購物車等的獨立微服務。

不可避免地，您必須設定和配置許多動態部件才能……

注意：2018 年 4 月修訂

Spring MVC 提供了幾種補充的異常處理方法，但是，在教授 Spring MVC 時，我經常發現我的學生對它們感到困惑或不適應。

今天我將向您展示可用的各種選項。我們的目標是儘可能在 Controller 方法中“不”顯式處理異常。它們是一個橫切關注點，最好在專門的程式碼中單獨處理。

有三個選項：按異常、按控制器或全域性。

一個演示應用程式顯示此處討論的要點，可在 http://github.com/paulc4/mvc-exceptions 找到。請參閱示例應用程式……

在我之前的文章中，我介紹了內容協商的概念以及 Spring MVC 用於確定所請求內容的三個策略。

在這篇文章中，我想專門擴充套件這個概念，以使用 ContentNegotiatingViewResolver (或 CNVR) 支援不同內容型別的多個檢視。

快速概覽

由於我們已經知道如何從之前的文章中設定內容協商，因此使用它在多個檢視之間進行選擇非常簡單。只需像這樣定義一個 CNVR

    <!--
      // View resolver that delegates to other view resolvers based on the
      // content type…

使用 Spring MVC 生成輸出有兩種方式

• 您可以使用 RESTful @ResponseBody 方法和 HTTP 訊息轉換器，通常用於返回 JSON 或 XML 等資料格式。程式客戶端、移動應用程式和啟用 AJAX 的瀏覽器是常見的客戶端。
• 或者，您可以使用檢視解析。儘管檢視完全能夠根據您的需要生成 JSON 和 XML（更多內容將在我的下一篇文章中介紹），但檢視通常用於為傳統的 Web 應用程式生成 HTML 等表示格式。
• 實際上還有第三種可能性——有些應用程式需要兩者，Spring MVC 很容易支援這種組合。我們將在最後回到這一點。

無論哪種情況，您都需要處理控制器返回的相同資料的多種表示形式（或檢視）。確定要返回哪種資料格式稱為內容協商。

有三種情況我們需要知道要在 HTTP 響應中傳送哪種資料格式

• HttpMessageConverters： 確定要使用的正確轉換器。
• 請求對映： 將傳入的 HTTP 請求對映到返回不同格式的不同方法。
• 檢視解析： 選擇要使用的正確檢視。

確定使用者請求的格式依賴於 ContentNegotationStrategy。開箱即用提供了預設實現，但您也可以根據需要實現自己的。

在這篇文章中，我想討論如何配置和使用 Spring 的內容協商，主要是在使用 HTTP 訊息轉換器的 RESTful 控制器方面。在稍後的文章中，我將展示如何專門使用 Spring 的 ContentNegotiatingViewResolver 來設定內容協商……