Ну не совсем, во втором примере сложная кодегенерация и страдания при дебаге(ну, вдруг), а у меня обычный код работающй с хттп.
1. Это да, ок. С другой стороны, мы же не знаем, какой апи хочет конкретный клиент. По идее, если клиенту надо, он докрутит там где надо, и тут уже нет принципиально разницы, докрутит ли он правила кодогенерации чтобы получить особенную версию клиента, либо же завраппит существующий клиент нужным ему образом непосредственно в коде.
2. Я не совсем понимаю, что именно может сломаться? Эта реализация исключительно рантаймовая, просто общим образом реализуется уже существующий интерфейс.
Добавляется новый метод в интерфейс — оно автоматом подхватывает новый метод и продолжает работать. Меняется апи — ошибка компиляции во всех местах где использовалось старое апи.
Единственное что, рефлексия, почему-то некоторые ее не любят. =)
Service это чистый клиентский интерфейс.
ServiceImpl это реализация сервиса с хттп маппингом.
Фабрика генерит проксю удовлетворяющую интерфейсу Service и занимающуюся конвертацией параметров в пригодный для реализации вид, будь это хттп или еще какой-то протокол, главное чтобы оно конфигурилось атрибутами.
Клиент зависит от Service интерфейса, когда интерфейс меняется, код перестает компилиться.
В общем-то это почти то же самое что и в статье, только чисто в рантайме, без коодгенерации.
Почему нельзя? Есть интерфейс сервиса, все что нужно это создать прокси инстанс этого интерфейса который будет делать то что сейчас делает сгенерированный код — смотреть на реализацию и по атрибутам прочухивать какие параметры как сериализовывать. Меняется интерфейс сервиса — ломаются места использования прокси.
Единственная проблема это необходимость иметь доступ к реализации интерфейса при создании прокси, но, с другой стороны, реализация сама по себе является интерфейсом, поскольку именно там описано по какому урлу идти с каким хттп методом.
1. Это да, ок. С другой стороны, мы же не знаем, какой апи хочет конкретный клиент. По идее, если клиенту надо, он докрутит там где надо, и тут уже нет принципиально разницы, докрутит ли он правила кодогенерации чтобы получить особенную версию клиента, либо же завраппит существующий клиент нужным ему образом непосредственно в коде.
2. Я не совсем понимаю, что именно может сломаться? Эта реализация исключительно рантаймовая, просто общим образом реализуется уже существующий интерфейс.
Добавляется новый метод в интерфейс — оно автоматом подхватывает новый метод и продолжает работать. Меняется апи — ошибка компиляции во всех местах где использовалось старое апи.
Единственное что, рефлексия, почему-то некоторые ее не любят. =)
tpcg.io/Aw5FAU
Service это чистый клиентский интерфейс.
ServiceImpl это реализация сервиса с хттп маппингом.
Фабрика генерит проксю удовлетворяющую интерфейсу Service и занимающуюся конвертацией параметров в пригодный для реализации вид, будь это хттп или еще какой-то протокол, главное чтобы оно конфигурилось атрибутами.
Клиент зависит от Service интерфейса, когда интерфейс меняется, код перестает компилиться.
В общем-то это почти то же самое что и в статье, только чисто в рантайме, без коодгенерации.
Единственная проблема это необходимость иметь доступ к реализации интерфейса при создании прокси, но, с другой стороны, реализация сама по себе является интерфейсом, поскольку именно там описано по какому урлу идти с каким хттп методом.
Разве того же самого нельзя добиться простым проксированием в рантайме?