Предыстория
Несколько месяцев назад поступила задача по написанию HTTP API работы с продуктом компании, а именно обернуть все запросы с помощью RestTemplate и последующим перехватом информации от приложения и модификации ответа. Примерная реализация сервиса по работе с приложением была таковая:
if (headers == null) {
headers = new HttpHeaders();
}
if (headers.getFirst("Content-Type") == null) {
headers.add("Content-Type", MediaType.APPLICATION_JSON_VALUE);
}
HttpEntity<Object> entity;
if (body == null) {
entity = new HttpEntity<>(headers);
} else {
entity = new HttpEntity<>(body, headers);
}
final String uri = String.format("%s%s/%s", workingUrl, apiPath, request.info());
final Class<O> type = (Class<O>) request.type();
final O response = (O)restTemplate.exchange(uri, request.method(), entity, type);
… простенький метод, принимающий тип, тело и заголовки запроса. И все бы хорошо, но выглядело как костыль и не особо юзабельно в контексте Spring.
И пока товарищи коллеги писали на старом механизме функционал в своих ветках, мне пришла в голову гениальнейшая идея — а почему бы не писать эти запросы "в одну строчку" (like Feign).
Идея
У нас в руках имеется мощный DI контейнер Spring, так почему бы не использовать его функционал в полной мере? В частности инициализации Data репозиториев на примере Jpa. Предо мной стояла задача инициализация класса типа интерфейс в контексте Spring и три варианта решения перехвата вызова метода, как типичной реализации — Aspect, PostProcess и BeanDefinitionRegistrar.
Кодовая база
Первым делом — аннотации, куда же без них, иначе как конфигурировать запросы.
1) Mapping — аннотация, идентифицирующая интерфейс как компонент HTTP вызовов.
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Mapping {
/**
* Registered service application name, need for config
*/
String alias();
}
