簡介

自從我教第一堂 Core Spring 課程以來，已經快 10 年了。當時幾乎所有東西都是 XML，例如，設定 JPA 或 Spring Security 可能會非常困難。Spring 在這段時間裡已經成熟了很多，元件掃描、Java 配置和 Spring Boot 使其使用起來更加有趣。並且 Spring 專案 的數量也顯著增加。

Pivotal Training 繼續加強我們的 Spring 課程並推出新課程 - 包括 Spring Boot Developer 和 Spring Cloud Services。 我已提供這些課程的概述...

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

更多資訊

如需更多資訊並查看我們完整的應用程式框架、雲原生和巨量資料套件課程，請造訪 Pivotal 學院。

簡介

注意： 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）支援不同內容類型的多個 View。

快速概觀

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

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

有兩種使用 Spring MVC 產生輸出的方法

• 您可以使用 RESTful @ResponseBody 方法和 HTTP 訊息轉換器，通常返回 JSON 或 XML 等資料格式。程式化用戶端、行動應用程式和支援 AJAX 的瀏覽器是常見的用戶端。
• 或者，您可以使用View 解析。 雖然 View 完全能夠在您希望的情況下生成 JSON 和 XML（在我的下一篇文章中會詳細介紹），但 View 通常用於為傳統 Web 應用程式生成 HTML 等表示格式。
• 實際上還有第三種可能性 - 有些應用程式需要兩者，Spring MVC 可以輕鬆支援這種組合。 我們將在最後回到這一點。

無論哪種情況，您都需要處理控制器傳回的相同資料的多種表示形式（或 View）。 計算出要傳回哪種資料格式稱為內容協商。

在以下三種情況下，我們需要知道要在 HTTP 回應中傳送哪種類型的資料格式

• HttpMessageConverters： 確定要使用的正確轉換器。
• Request Mappings： 將傳入的 HTTP 請求對應到傳回不同格式的不同方法。
• View Resolution： 選擇要使用的正確 View。

確定使用者請求的格式取決於 ContentNegotationStrategy。 有預設實現可直接使用，但您也可以根據需要實現自己的實現。

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