Как стать автором
Обновить

Комментарии 5

НЛО прилетело и опубликовало эту надпись здесь

Просто потому что смог :)
Обычно когда 100500 раз одно раз и тоже проверяешь, будь то в контроллере или сервисе — имеет смысл вывести куда то выше.
Я бы наверное сделал обычный resolver где был бы валидатор. Пару минут времени.

«Выше» — в сервлет спецификации есть например фильтры. Не совсем может быть подходит под этот кейс, но сделать префильтр на них иногда проще и логичнее. Нам же не надо читать параметры реквеста? Нам же нужно только понять есть ли они там или нет, верно?

Такой вариант тоже рассматривался, как я написал ниже.

Опишу чуть подробнее ситуацию.


Был интерфейс контроллера


@RequestMapping("/useful")
@RestController
public interface UsefulDataHandler {
    SomeData getSomeData();
}

На основе этого интерфейса смежная система генерировала свою реализацию, которая под капотом обращалась к нашему контроллеру. Т.е. в этой системе чтобы получить SomeData нужно было просто вызвать метод.


public UsefulDataHandlerImpl implements UsefulDataHandler {
    SomeData getSomeData() {
        //do http request and return response
    }
}

Теперь представим, что мы добавляем еще один метод:


@RequestMapping("/useful")
@RestController
public interface UsefulDataHandler {
    SomeData getSomeData();
    AnotherData getAnotherData(@RequestParam Params params);
}

И здесь мы получаем ситуацию о которой я и писал. Мы должны по разному обрабатывать запросы.


На самом деле рассматривались и другие варианты решения, например, просто назначение методов на разные URL или через фильтры или через заголовки. Самое смешное, что пока никак не сделали.


К тому же статья не претендует на руководство как надо делать. Я столкнулся с копанием во внутренностях Spring, и этот опыт я посчитал интересным чтобы им поделиться.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории