引言

從我第一次教授 Core Spring 課程到現在已經快 10 年了。那時候幾乎所有東西都是 XML 配置，例如配置 JPA 或 Spring Security 會非常費力。與此同時，隨著元件掃描、Java 配置和 Spring Boot 的出現，Spring 變得更加成熟，使用起來也更加有趣。並且 Spring 專案的數量也大大增加了。

Pivotal Training 不斷改進我們的 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：確定要使用的正確轉換器。
• Request Mappings：將傳入的 HTTP 請求對映到返回不同格式的不同方法。
• View Resolution：選擇要使用的正確檢視。

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

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