Spring Boot та Web MVC, частина 2

Статичний вміст

За замовчуванням Spring Boot обробляє статичний вміст з каталогу /static (або /public або /resources, або /META-INF/resources) у classpath або з кореня ServletContext. Фреймворк використовує ResourceHttpRequestHandler із Spring MVC, тому ти можеш змінити цю логіку роботи, додавши власний WebMvcConfigurer та перевизначивши метод addResourceHandlers.

В автономному вебдодатку стандартний сервлет із контейнера не активовано. Його можна активувати за допомогою властивості server.servlet.register-default-servlet.

Стандартний сервлет виступає в ролі запасного варіанту, обробляючи вміст з кореня ServletContext якщо Spring не буде обробляти його. У більшості випадків такого не відбувається (якщо не змінити стандартну конфігурацію MVC), тому що Spring завжди здатний обробляти запити через DispatcherServlet.

За замовчуванням ресурси відображаються на /** , але можна тонко налаштувати це відображення через властивість spring.mvc.static-path-pattern. Наприклад, переміщення всіх ресурсів до /resources/** можна виконати так:

spring.mvc.static-path-pattern=/resources/**

spring:
    mvc:
        static-path-pattern: "/resources/**"

Ти також можеш налаштовувати розташування статичних ресурсів за допомогою властивості spring.web.resources.static-locations (замінивши значення за замовчуванням на список розташування каталогів). Кореневий шлях контексту сервлета, "/", автоматично додається як місце розташування.

На додаток до "стандартних" статичних розташування ресурсів, згаданих раніше, особливе місце відводиться вмісті Webjars. Будь-які ресурси шляхом /webjars/** обробляються з jar-файлів, якщо вони упаковані у формат Webjars.

Spring Boot також підтримує розширений функціонал роботи з ресурсами, що надаються Spring MVC, що дозволяє використовувати такі сценарії, як відключення кешування статичних ресурсів або використання URL-адрес для Webjars, які не залежать від версії.

Щоб використовувати URL-адреси Webjars, які не залежать від версії, додай залежність webjars-locator-core. Потім оголоси свій Webjar. На прикладі jQuery додавання "/webjars/jquery/jquery.min.js" призводить до "/webjars/jquery/x.y.z/jquery.min.js", де x.y.z — версія Webjar.

Для використання функції відключення кешування в наступній конфігурації налаштовано рішення для відключення кешування всіх статичних ресурсів шляхом додавання хешу вмісту, наприклад < link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>, до URL-адреси:

spring.web.resources.chain.strategy.content.enabled=true
spring.web.resources.chain.strategy.content.paths=/**

spring:
  web:
    resources:
      chain:
        strategy:
          content:
            enabled: true
            paths: "/**"

При динамічному завантаженні ресурсів, наприклад, за допомогою завантажувача модулів JavaScript, перейменування файлів неможливе. Тому підтримуються інші стратегії, які можна комбінувати. Стратегія з використанням "фіксації (fixed)" додає статичний рядок версії до URL-адреси без зміни імені файлу, як показано в наступному прикладі:

spring.web.resources.chain.strategy.content.enabled=true
spring.web.resources.chain.strategy.content.paths=/**
spring.web.resources.chain.strategy.fixed.enabled=true
spring.web.resources.chain.strategy.fixed.paths=/js/lib/
spring.web.resources.chain.strategy.fixed.version=v12

spring:
  web:
    resources:
      chain:
        strategy:
          content:
            enabled: true
            paths: "/**"
          fixed:
            enabled: true
            paths: "/js/lib/"
            version: "v12"

При такій конфігурації модулі JavaScript, розташовані в каталозі " /js/lib/", використовують стратегію фіксованого версіонування ("/v12/js/lib/mymodule.js"), в той час як інші ресурси, як і раніше, використовують стратегію на основі вмісту (<link href="/css/spring-2a2d595e6ed9a0b24f027f2b63b134d6.css"/>).

Додаткові опції, що підтримуються, див. WebProperties.Resources.

Початкова сторінка

Spring Boot підтримує як статичні, так і шаблонні початкові сторінки. Спочатку фреймворк шукає файл index.html у налаштованих місцях статичного вмісту. Якщо шаблон не знайдено, він шукає шаблон index. Якщо один з них буде знайдений, то він буде автоматично використаний як початкова сторінка програми.

Кастомний Favicon

Як і у випадку з іншими статичними ресурсами, Spring Boot перевіряє наявність favicon.ico у конфігурованих місцях статичного контенту. Якщо такий файл присутній, він автоматично використовується як значок вебсторінки (favicon) для програми.

Зіставлення шляхів та узгодження вмісту

Spring MVC може зіставляти вхідні HTTP-запити з обробниками, переглядаючи шлях запиту та зіставляючи його з відображеннями, визначеними в додатку (наприклад, анотаціями @GetMapping для методів контролера).

Spring Boot за замовчуванням відключає зіставлення суфіксальних шаблонів, що означає, що запити типу "GET /projects/spring-boot.json" не будуть зіставлені з відображенням @GetMapping("/projects/spring-boot"). Це вважається найбільш оптимальним методом додатків Spring MVC. У минулому ця функція була корисною в основному для HTTP-клієнтів, які не надсилали належні заголовки запиту "Accept"; необхідно було переконатися, що клієнту надіслано коректний тип вмісту. В даний час узгодження вмісту стало набагато надійнішим.

Існують й інші способи розібратися з HTTP-клієнтами, які не завжди надсилають правильні заголовки запиту "Accept". Замість використання суфіксальної відповідності можна використовувати параметр запиту, щоб запити типу "GET /projects/spring-boot?format=json" були гарантовано зіставлені з @GetMapping("/projects/spring-boot" ):

spring.mvc.contentnegotiation.favor-parameter=true

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true 

Або якщо ти волієш використовувати інше ім'я параметра:

spring.mvc.contentnegotiation.favor-parameter=true
spring.mvc.contentnegotiation.parameter-name=myparam

spring:
  mvc:
    contentnegotiation:
      favor-parameter: true
      parameter-name: "myparam"

Більшість стандартних типів середовища передачі даних підтримуються "з коробки", але ти також можеш визначати нові:

spring. mvc.contentnegotiation.media-types.markdown=text/markdown

spring:
  mvc:
    contentnegotiation:
      media-types:
        markdown: "text/markdown"

Зіставлення суфіксальних шаблонів зі зразком застаріло і буде видалено в майбутньому випуску. Якщо тобі зрозумілі всі застереження і все ж таки ти хочеш, щоб програма використовувала суфіксальне зіставлення шаблонів зі зразком, необхідно виконати наступну конфігурацію:

spring.mvc.contentnegotiation.favor-path-extension=true
spring.mvc.pathmatch.use-suffix-pattern=true

spring:
  mvc:
    contentnegotiation:
      favor-path-extension: true
    pathmatch:
      use-suffix-pattern: true

До того ж, замість відкриття всіх суфіксальних шаблонів більш надійним методом буде забезпечення підтримки виключно зареєстрованих суфіксальних шаблонів:

spring.mvc.contentnegotiation.favor-path-extension=true
spring.mvc.pathmatch.use-registered-suffix-pattern=true

spring:
  mvc:
    contentnegotiation:
      favor-path-extension: true
    pathmatch:
      use-registered-suffix-pattern: true

Починаючи з версії Spring Framework 5.3, Spring MVC підтримує кілька стратегій реалізації для зіставлення шляхів запиту з обробниками контролера. Раніше вона підтримувала лише стратегію AntPathMatcher, але тепер також пропонує PathPatternParser. Spring Boot тепер передбачає конфігураційну властивість, що забезпечує вибір та підключення нової стратегії:

spring.mvc.pathmatch.matching- strategy=path-pattern-parser

spring:
  mvc:
    pathmatch:
      matching-strategy: "path-pattern-parser"

Для отримання більш детальної інформації про те, чому слід звернути увагу на цю нову реалізацію, див. спеціальний пост у блозі.

ConfigurableWebBindingInitializer

Spring MVC використовує WebBindingInitializer для ініціалізації WebDataBinder для конкретного запиту. Якщо ти створиш свій власний ConfigurableWebBindingInitializer, позначений анотацією @Bean, Spring Boot автоматично конфігурує Spring MVC для його використання.