Анотовані контролери

@PostMapping("/owners/{ownerId}/pets/{petId}/edit")
public Mono<String> processSubmit(@Valid @ModelAttribute("pet") Mono<Pet> petMono) {
return petMono
.flatMap(pet -> {
    // ...
})
.onErrorResume(ex -> {
    // ...
});
}

@PostMapping("/owners/{ownerId}/pets/{petId}/edit")
fun processSubmit(@Valid @ModelAttribute("pet") petMono: Mono<Pet>): Mono<String> {
return petMono
    .flatMap { pet ->
        // ...
    }
    .onErrorResume{ ex ->
        // ...
    }
}

Зверни увагу, що використовувати анотацію @ ModelAttribute необов'язково — наприклад, для встановлення його атрибутів. За замовчуванням будь-який аргумент, який не є простим типом значення (як визначено BeanUtils#isSimpleProperty) і не дозволяється жодним іншим розпізнавальником аргументів, обробляється так, якби він був анотований @ModelAttribute.

@SessionAttributes

@SessionAttributes використовується для зберігання атрибутів моделі в WebSession між запитами. Це анотація лише на рівні типу, яка оголошує атрибути сесії, використовувані конкретним контролером. Тут зазвичай перераховуються імена атрибутів моделі або типи атрибутів моделі, які повинні прозоро зберігатися в сесії для наступних запитів на доступ.

Розглянемо наступний приклад:

 @Controller
@SessionAttributes("pet") 
public class EditPetForm {
// ...
}

@Controller
@SessionAttributes("pet") 
class EditPetForm {
// ...
} 

При першому запиті, якщо модель додається до атрибуту моделі з ім'ям pet, він автоматично просувається в WebSession і зберігається в ній. Він залишається там, поки інший метод контролера не використовує аргумент методу SessionStatus для очищення сховища, як показано в наступному прикладі:

@Controller
@SessionAttributes("pet") 
public class EditPetForm {
// ...
@PostMapping("/pets/{id}")
public String handle(Pet pet, BindingResult errors, SessionStatus status) { 
if (errors.hasErrors()) {
    // ...
}
    status.setComplete();
    // ...
}
}
}

@Controller
@SessionAttributes("pet") 
class EditPetForm {
// ...
@PostMapping("/pets/{id}")
fun handle(pet: Pet, errors: BindingResult, status: SessionStatus): String { 
if (errors.hasErrors()) {
    // ...
}
status.setComplete()
// ...
}
}

@SessionAttribute

Якщо потрібний доступ до заздалегідь існуючих атрибутів сесії, які управляються глобально (тобто поза контролером — наприклад, фільтром) і можуть бути присутніми або відсутніми, то можна використовувати анотацію @SessionAttribute для параметра методу, як показано в наступному прикладі:

@GetMapping("/")
public String handle(@SessionAttribute User user) { 
// ...
}

@GetMapping("/")
fun handle(@SessionAttribute user: User): String { 
// ...
}

Для випадків використання, які вимагають додавання або видалення атрибутів сесії, зверни увагу на можливість впровадження WebSession у метод контролера.

Для тимчасового зберігання атрибутів моделі в сесії як частини робочого процесу контролера, розглянь можливість використання SessionAttributes.

@RequestAttribute

Аналогічно анотації @SessionAttribute, можна використовувати анотацію @RequestAttribute для здійснення доступу до вже існуючих атрибутів запиту, створеного раніше (наприклад, WebFilter), як показано в наступному прикладі:

@GetMapping("/")
public String handle(@RequestAttribute Client client) { 
// ...
}

@GetMapping("/")
fun handle(@RequestAttribute client: Client): String { 
// ...
}

Багатокомпонентний вміст

ServerWebExchange забезпечує доступ до багатокомпонентного вмісту. Найкращий спосіб обробки форми завантаження файлу (наприклад, з браузера) у контролері — це прив'язка даних до об'єкта команди, як показано в наступному прикладі:

class MyForm {
private String name;
private MultipartFile file;
// ...
}
@Controller
public class FileUploadController {
@PostMapping("/form")
public String handleFormUpload(MyForm form, BindingResult errors) {
// ...
}
}

class MyForm(
val name: String,
val file: MultipartFile)
@Controller
class FileUploadController {
@PostMapping("/form")
fun handleFormUpload(form: MyForm, errors: BindingResult): String {
// ...
}
}

Ти також можеш надсилати багатокомпонентні запити від небраузерних клієнтів у сценарії за допомогою RESTful служб. У цьому прикладі використовується файл разом з JSON:

POST /someUrl
Content-Type: multipart/mixed
--edt7Tfrdusa7r3lNQc79vXuhIIMlatb7PQg7Vp
Content-Disposition: form-data; name="meta-data"
Content-Type: application/json; charset=UTF-8
Content-Transfer-Encoding: 8bit
{
"name": "value"
}
--edt7Tfrdusa7r3lNQc79vXuhIIMlatb7PQg7Vp
Content-Disposition: form-data; name="file-data"; filename="file.properties"
Content-Type: text/xml
Content-Transfer-Encoding: 8bit
... File Data ...

Можна отримати доступ до окремих компонентів за допомогою анотації @RequestPart, як показано в наступному прикладі:

@PostMapping("/")
public String handle(@RequestPart("meta-data") Part metadata, 
@RequestPart("file-data") FilePart file) { 
// ...
}

@PostMapping("/")
fun handle(@RequestPart("meta-data") Part metadata,
@RequestPart("file-data") FilePart file): String { 
// ...
}

Щоб десеріалізувати сирий вміст компонента (наприклад, в JSON — аналогічно інструкції @RequestBody), можна оголосити конкретний цільовий Object замість Part, як показано в наступному прикладі:

@PostMapping("/")
public String handle(@RequestPart("meta-data") MetaData metadata) { 
// ...
}

@PostMapping("/")
fun handle(@RequestPart("meta-data") metadata: MetaData): String { 
// ...
}

Можно використати анотацію @RequestPart у поєднанні з анотацією javax.validation.Valid або анотацією @Validated зі Spring, що призведе до застосування стандартної Bean Validation. Помилки валідації призводять до виникнення WebExchangeBindException, внаслідок чого видається відповідь 400 (BAD_REQUEST). Виняток містить BindingResult з деталями помилки і також може бути оброблено в методі контролера шляхом оголошення аргументу з асинхронною функцією-оберткою та подальшого використання операторів, пов'язаних з помилкою:

@PostMapping("/")
public String handle(@Valid @RequestPart("meta-data") Mono<MetaData> metadata) {
// використовуємо один з операторів onError*...
}

@PostMapping("/")
fun handle(@Valid @RequestPart("meta-data") metadata: MetaData): String {
// ...
}

Щоб отримати доступ до всіх багатокомпонентних даних у вигляді MultiValueMap, ви можеш використовувати анотацію @RequestBody, як це показано в наступному прикладі:

@PostMapping("/")
public String handle(@RequestBody Mono<MultiValueMap<String, Part>> parts) { 
// ...
}

@PostMapping("/")
fun handle(@RequestBody parts: MultiValueMap<String, Part>): String { 
// ...
}

Для послідовного потокового доступу до багатокомпонентних даних можна використовувати анотацію @RequestBody з Flux<Part> (або Flow<Part> у Kotlin), як показано в наступному прикладі:

@PostMapping("/")
public String handle(@RequestBody Flux<Part> parts) { 
// ...
}

@PostMapping("/")
fun handle(@RequestBody parts: Flow<Part>): String { 
// ...
}

@RequestBody

Анотацію @RequestBody можна використовувати, щоб прочитати тіло запиту і десеріалізувати його в об'єкт Object HttpMessageReader. У цьому прикладі використовується аргумент, анотований @RequestBody:

@PostMapping("/accounts")
public void handle(@RequestBody Account account) {
// ...
}

 @PostMapping("/accounts")
fun handle(@RequestBody account: Account) {
// ...
}

На відміну від Spring MVC, у WebFlux аргумент методу, позначеного анотацією @RequestBody, підтримує реактивні типи і повністю неблокуюче читання та (клієнт-серверну) потокову передачу.

@PostMapping("/accounts")
public void handle(@RequestBody Mono<Account> account) {
// ...
}

@PostMapping("/accounts")
fun handle(@RequestBody accounts: Flow<Account>) {
// ...
}

Ти можеш використовувати опцію кодеків повідомлень, що передаються за протоколом HTTP, в конфігурації WebFlux для конфігурування або кастомного налаштування засобів читання повідомлень.

Анотацію @RequestBody можна застосовувати в поєднанні з анотацією javax.validation.Valid або анотацією @Validated із Spring, що призводить до застосування стандартної Bean Validation. Помилки валідації викликають WebExchangeBindException, що призводить до відповіді 400 (BAD_REQUEST). Виняток містить BindingResult з деталями помилки і також може бути оброблено в методі контролера шляхом оголошення аргументу з асинхронною функцією-обгорткою та подальшого використання операторів, пов'язаних з помилкою:

@PostMapping("/accounts")
public void handle(@Valid @RequestBody Mono<Account> account) {
// використовуємо один з операторів onError*...
}

@PostMapping("/accounts")
fun handle(@Valid @RequestBody account: Mono<Account>) {
// ...
}

HttpEntity

HttpEntity більш-менш ідентичний анотації @RequestBody в плані використання, але ґрунтується на об'єкті-контейнер, який відкриває заголовки та тіло запиту. У цьому прикладі використовується HttpEntity:

@PostMapping("/accounts")
public void handle(HttpEntity<Account> entity) {
// ...
}

@PostMapping("/accounts")
fun handle(entity: HttpEntity<Account>) {
// ...
}

@ResponseBody

Анотацію @ResponseBody можна використовувати нам методом, щоб повернення серіалізувалося в тіло відповіді через HttpMessageWriter. У цьому прикладі показано, як це зробити:

@GetMapping("/accounts/{id}")
@ResponseBody
public Account handle() {
// ...
}

@GetMapping("/accounts/{id}")
@ResponseBody
fun handle(): Account {
// ...
}

@ResponseBody також підтримується лише на рівні класу, у разі вона успадковується всіма методами контролера. У цьому полягає дія анотації @RestController, яка є нічим іншим, як мета-анотацією, позначеною анотаціями @Controller та @ResponseBody.

@ResponseBody підтримує реактивні типи, що означає, що ти можеш повертати типи Reactor або RxJava і отримувати відповідні асинхронні значення, які вони створюють.

Ти можеш комбінувати методи, позначені анотацією @ResponseBody, з представленнями серіалізації формату JSON.

Можна використовувати опцію кодеків повідомлень, що передаються за протоколом HTTP, у конфігурації WebFlux для конфігурування або кастомного налаштування пристроїв читання повідомлень.

ResponseEntity

Атрибут ResponseEntity подібний до анотації @ResponseBody, але зі статусом і заголовками. Наприклад:

@GetMapping("/something")
public ResponseEntity<String> handle() {
String body = ... ;
String etag = ... ;
return ResponseEntity.ok().eTag(etag).body(body);
}

@GetMapping("/something")
fun handle(): ResponseEntity<String> {
val body: String = ...
val etag: String = ...
return ResponseEntity.ok().eTag(etag).build(body)
}

WebFlux підтримує використання реактивного типу з одним значенням для асинхронного створення ResponseEntity та/або реактивних типів з одним та кількома значеннями для тіла. Це дозволяє використовувати різні асинхронні відповіді з ResponseEntity таким чином:

• ResponseEntity<Mono<T>> або ResponseEntity<Flux<T>> негайно повідомляють статус і заголовки відповіді, в той час як тіло відповіді надається асинхронно в пізніший момент. Використовуємо Mono, якщо тіло складається з 0..1 значень, або Flux, якщо воно може створювати декілька значень.

• Mono<ResponseEntity<T>> передбачає всі три параметри — статус відповіді, заголовки і тіло — асинхронно в пізніший момент. Це дозволяє змінювати статус відповіді та заголовки залежно від результатів асинхронної обробки запиту.

• Mono<ResponseEntity<Mono< code>Mono<ResponseEntity<Flux<T>>> є ще однією можливою, хоча і менш поширеною альтернативою. Спочатку вони асинхронно надають статус відповіді та заголовки, а потім, у другу чергу, тіло відповіді також асинхронно.

Jackson JSON

Spring передбачає підтримку бібліотеки Jackson JSON.

Подання JSON

Spring WebFlux передбачає вбудовані засоби підтримки подання серіалізації з бібліотеки Jackson, яка дозволяє візуалізувати виключно підмножину всіх полів Object. Щоб використовувати його з методами контролера, анотованими @ResponseBody, або класом ResponseEntity, можна використовувати анотацію @JsonView з Jackson для активації класу представлення серіалізації, як показано в наступному прикладі:

@RestController
public class UserController {
@GetMapping("/user")
@JsonView(User.WithoutPasswordView.class)
public User getUser() {
return new User("eric", "7!jd#h23");
}
}
public class User {
public interface WithoutPasswordView {};
public interface WithPasswordView extends WithoutPasswordView {};
private String username;
private String password;
public User() {
}
public User(String username, String password) {
this.username = username;
this.password = password;
}
@JsonView(WithoutPasswordView.class)
public String getUsername() {
return this.username;
}
@JsonView(WithPasswordView.class)
public String getPassword() {
return this.password;
}
}

@RestController
class UserController {
@GetMapping("/user")
@JsonView(User.WithoutPasswordView::class)
fun getUser(): User {
return User("eric", "7!jd#h23")
}
}
class User(
@JsonView(WithoutPasswordView::class) val username: String,
@JsonView(WithPasswordView::class) val password: String
) {
interface WithoutPasswordView
interface WithPasswordView : WithoutPasswordView
}

Model

Ти можеш використовувати анотацію @ModelAttribute:

• Як аргумент методу в методах з анотацією @RequestMapping для створення або забезпечення доступу до об'єкта з моделі та прив'язки його до запиту через WebDataBinder.

• Як анотацію на рівні методу в класах, позначених анотаціями @Controller або @ControllerAdvice, що допомагає ініціалізувати модель перед викликом методу з анотацією @RequestMapping.

• На методі з анотацією @RequestMapping, щоб позначити його значення, що повертається як атрибут моделі.

У цьому розділі описано методи, анотовані @ModelAttribute, або другий пункт з попереднього списку. Контролер може мати будь-яку кількість методів, позначених анотацією @ModelAttribute. Усі такі методи викликаються перед методами, позначеними анотацією @RequestMapping у тому контролері. Метод із анотацією @ModelAttribute також можна розділити між контролерами через анотацію @ControllerAdvice.

Методи з анотацією @ModelAttribute мають гнучкі сигнатури методов. Вони підтримують багато з тих самих аргументів, як і методи, помічені анотацією @RequestMapping, крім самої анотації @ModelAttribute чи всього, що пов'язані з тілом запиту.

У наступному прикладі використовується метод, позначений анотацією @ModelAttribute:

@ModelAttribute
public void populateModel(@RequestParam String number, Model model) {
model.addAttribute(accountRepository.findAccount(number));
// add more ...
}}

@ModelAttribute
fun populateModel(@RequestParam number: String, model: Model) {
model.addAttribute(accountRepository.findAccount(number))
// add more ...
}

У наступному прикладі додано тільки один атрибут:

@ModelAttribute
public Account addAccount(@RequestParam String number) {
return accountRepository.findAccount(number);
}

@ModelAttribute
fun addAccount(@RequestParam number: String): Account {
return accountRepository.findAccount(number);
}

Spring WebFlux, на відміну від Spring MVC, явно підтримує реактивні типи в моделі (наприклад, Mono<Account> або io.reactivex.Single<Account>). Такі асинхронні атрибути моделі можна прозоро дозволити (і оновити модель) у їх фактичні значення під час виклику @RequestMapping, якщо аргумент з анотацією @ModelAttribute оголошено без функції-обгортки, як показано у наступному прикладі:

@ModelAttribute
public void addAccount(@RequestParam String number) {
Mono<Account> accountMono = accountRepository.findAccount(number);
model.addAttribute("account", accountMono);
}
@PostMapping("/accounts")
public String handle(@ModelAttribute Account account, BindingResult errors) {
// ...
}

import org.springframework.ui.set
@ModelAttribute
fun addAccount(@RequestParam number: String) {
val accountMono: Mono<Account> = accountRepository.findAccount(number)
model["account"] = accountMono
}
@PostMapping("/accounts")
fun handle(@ModelAttribute account: Account, errors: BindingResult): String {
// ...
}

Крім того, будь-які атрибути моделі, що мають функцію-обгортку реактивного типу, дозволяються в їх фактичні значення (а модель оновлюється) безпосередньо перед візуалізацією подання.

Також можна використовувати анотацію @ModelAttribute як анотацію на рівні методу для методів, помічених анотацією @RequestMapping, і в цьому випадку значення методу, що повертається анотацією @RequestMapping інтерпретується як атрибут моделі. Зазвичай робити це не потрібно, оскільки така логіка роботи задана за замовчуванням у HTML-контролерах, якщо тільки значення, що повертається, не є String, яка в іншому випадку буде інтерпретована як ім'я уявлення. Анотація @ModelAttribute також може допомогти кастомно налаштувати ім'я атрибута моделі, як показано в наведеному нижче прикладі:

@GetMapping("/accounts/{id}")
@ModelAttribute("myAccount")
public Account handle() {
// ...
return account;
}

@GetMapping("/accounts/{id}")
@ModelAttribute("myAccount")
fun handle(): Account {
// ...
return account
}

DataBinder

Класи з анотацією @Controller або @ControllerAdvice можуть мати методи, анотовані @InitBinder, щоб ініціалізувати екземпляри WebDataBinder. Ті, у свою чергу, використовуються для:

• Прив'язування параметрів запиту (тобто даних форми або запиту) до об'єкта моделі.

• Перетворення значень запиту на основі String(таких як параметри запиту, змінні шляхи, заголовки, cookie та ін) в цільовий тип аргументів методу контролера.

• Форматування значень об'єктів моделі як String значень при візуалізації HTML-форм.

Методи з анотацією @InitBinder можуть реєструвати специфічні для контролера компоненти java.beans.PropertyEditor або Converter та Formatter із Spring. До того ж, можна використовувати Java-конфігурацію WebFlux для реєстрації типів Converter і Formatter у спільно використовуваному на глобальному рівні FormattingConversionService.

Методи, позначені анотацією @InitBinder, підтримують багато з тих же аргументів, що й методи з анотацією @RequestMapping, за винятком аргументів, анотованих @ModelAttribute (Об'єкт команди). Як правило, вони оголошуються з аргументом WebDataBinder для реєстрації та значенням void, що повертається. У цьому прикладі використовується анотація @InitBinder:

@Controller
public class FormController {
@InitBinder 
public void initBinder(WebDataBinder binder) {
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
dateFormat.setLenient(false);
binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false));
}
// ...
}

class FormController {
@InitBinder 
fun initBinder(binder: WebDataBinder) {
val dateFormat = SimpleDateFormat("yyyy-MM-dd")
dateFormat.isLenient = false
binder.registerCustomEditor(Date::class.java, CustomDateEditor(dateFormat, false))
}
// ...
}

Як варіант, при використанні конфігурації на основі Formatter через загальний FormattingConversionService можна повторно використовувати той самий підхід і зареєструвати екземпляри Formatter, специфічні для контролера, як показано в наступному прикладі:

public class FormController {
@InitBinder
protected void initBinder(WebDataBinder binder) {
binder.addCustomFormatter(new DateFormatter("yyyy-MM-dd")); 
}
// ...
}

@Controller
class FormController {
@InitBinder
fun initBinder(binder: WebDataBinder) {
binder.addCustomFormatter(DateFormatter("yyyy-MM-dd")) 
}
// ...
}

Структура моделі

У контексті вебдодатків прив'язування даних передбачає прив'язку параметрів HTTP-запиту (тобто даних форми або параметрів запиту) до властивостей об'єкта моделі та його вкладених об'єктів.

Для прив'язки даних відкриті лише public властивості, що відповідають угоди про ім'я JavaBeans – наприклад, методи public String getFirstName() та public void setFirstName(String) для властивості firstName.

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

Наприклад, за наявності кінцевої точки даних HTTP-форми шкідливий клієнт може передати значення для властивостей, які існують у графі об'єктів моделі, але не є частиною HTML-форми, представленої в браузері. Це може призвести до того, що в об'єкт моделі та будь-який з його вкладених об'єктів будуть встановлені дані, оновлення яких не очікується.

Рекомендований підхід полягає у використанні спеціалізованого об'єкта моделі, який відкриває лише ті властивості, які стосуються відправки форми. Наприклад, у формі зміни адреси електронної пошти користувача об'єкт моделі повинен оголосити мінімальний набір властивостей, як у наступному ChangeEmailForm.

public class ChangeEmailForm {
private String oldEmailAddress;
private String newEmailAddress;
public void setOldEmailAddress(String oldEmailAddress) {
this.oldEmailAddress = oldEmailAddress;
}
public String getOldEmailAddress() {
return this.oldEmailAddress;
}
public void setNewEmailAddress(String newEmailAddress) {
this.newEmailAddress = newEmailAddress;
}
public String getNewEmailAddress() {
return this.newEmailAddress;
}
}

Якщо у тебе немає можливості або ти не бажаєш використовувати спеціалізований об'єкт моделі для кожного випадку використання прив'язки даних, то має обмежити властивості, які дозволені для прив'язки даних. В ідеалі цього можна досягти, зареєструвавши шаблони допустимих полів за допомогою методу setAllowedFields() у WebDataBinder.

Наприклад, щоб зареєструвати шаблони допустимих полів у вашому додатку, можна реалізувати метод, позначений анотацією @InitBinder, в компоненті з анотацією @Controller або @ControllerAdvice, як показано нижче:

@Controller
public class ChangeEmailController {
@InitBinder
void initBinder(WebDataBinder binder) {
binder.setAllowedFields("oldEmailAddress", "newEmailAddress");
}
// @RequestMapping methods, etc.
}

На додаток до реєстрації шаблонів допустимих полів, можна також зареєструвати шаблони неприпустимих полів за допомогою методу setDisallowedFields() у DataBinder та його підкласах. Однак зверни увагу, що "список, що допускає", безпечніший, ніж "список, що забороняє". Отже, використання setAllowedFields() слід віддати перевагу замість використання setDisallowedFields().

Зверни увагу, що зіставлення з шаблонами допустимих полів чутливе до регістру; тоді як зіставлення з шаблонами неприпустимих полів — ні. До того ж, поле, що відповідає шаблону неприпустимих полів, не буде прийнято, навіть якщо воно також відповідає шаблону в списку допустимих.

Також рекомендується не використовувати типи з твоєї моделі предметної області, такі як сутності JPA або Hibernate, як об'єкт моделі в сценаріях прив'язки даних.

Керування винятками

Класи з анотацією @Controller та @ControllerAdvice можуть мати методи, позначені анотацією @ExceptionHandler , для обробки винятків із методів контролера. Наступний приклад містить такий метод обробника:

@Controller
public class SimpleController {
// ...
@ExceptionHandler 
public ResponseEntity<String> handle(IOException ex) {
// ...
}
}

class SimpleController {
// ...
@ExceptionHandler 
fun handle(ex: IOException): ResponseEntity<String> {
// ...
}
}

Виняток може збігатися з поширюваним високорівневим винятком (наприклад, прямо генерований IOException) або з вкладеною причиною всередині виключення-обгортки (наприклад, IOException, обернене всередині IllegalStateException).

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

Підтримка методів, анотованих @ExceptionHandler, Spring WebFlux забезпечується за допомогою HandlerAdapter для методів з анотацією @RequestMapping.

Робота з винятками в REST API

Спільною вимогою для служб на основі REST є включення інформації про помилку в тіло відповіді. Spring Framework не здійснює це автоматично, оскільки вказівка інформації про помилку у тілі відповіді залежить від конкретної програми. Однак анотація @RestController може використовувати методи, позначені анотацією @ExceptionHandler, з значенням ResponseEntity, що повертається, для встановлення статусу і тіла відповіді. Такі методи також можуть бути оголошені в класах з анотацією @ControllerAdvice, щоб застосовувати їх на глобальному рівні.

Advice контролера

Зазвичай методи, позначені анотаціями @ExceptionHandler, @InitBinder та @ModelAttribute, застосовуються в межах класу @Controller (або ієрархії класів), в якому вони оголошені. Якщо тобі потрібно, щоб такі методи застосовувалися більш глобально (для всіх контролерів), можна оголосити їх у класі, анотованому @ControllerAdvice або @RestControllerAdvice.

Анотація @ControllerAdvice анотована за допомогою @Component, що означає, що такі класи можна реєструвати як бін Spring через сканування компонентів. Анотація @RestControllerAdvice — це складена анотація, яка позначена і анотацією @ControllerAdvice, і анотацією @ResponseBody, що означає, що методи з анотацією @ExceptionHandler візуалізуються в тілі відповіді через перетворення повідомлень (на відміну від дозволу уявлень або візуалізації шаблону).

При запуску класи інфраструктури для методів, анотованих @RequestMapping та @ExceptionHandler виявляють біни Spring, анотовані @ControllerAdvice, а потім застосовують їх методи під час виконання. Глобальні методи, анотовані за допомогою @ExceptionHandler (з анотації @ControllerAdvice) застосовуються після локальних (з анотації @Controller ). Навпаки, глобальні методи з анотаціями @ModelAttribute та @InitBinder застосовуються перед локальними.

За замовчуванням методи, позначені анотацією @ControllerAdvice застосовуються до кожного запиту (тобто всіх контролерів), але можна звузити коло контролерів, використовуючи атрибути анотації, як показано в наступному прикладі:

// Вибираємо метою всі контролери, анотовані за допомогою @RestController
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}
// Вибираємо метою всі контролери в певних пакетах
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}
// Вибираємо метою всі контролери, які призначаються певним класам
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
public class ExampleAdvice3 {}

// Вибираємо метою всі контролери, анотовані за допомогою @RestController
@ControllerAdvice(annotations = [RestController::class])
public class ExampleAdvice1 {}
// Вибираємо метою всі контролери в певних пакетах
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}
// Вибираємо метою всі контролери, які призначаються певним класам
@ControllerAdvice(assignableTypes = [ControllerInterface::class, AbstractController::class])
public class ExampleAdvice3 {}

Селектори в попередньому прикладі обчислюються під час виконання і можуть негативно вплинути на продуктивність при широкому використанні. Детальнішу інформацію дивіться в javadoc по анотації @ControllerAdvice.