Comments 21
Перегенерация клиентов на любое изменение апи, причем кривыми инструментами со странными зависимостями, отсутствие поддержки предыдущих версий API, и прочая прочая.
Есть тут люди которым он зашел? Может быть у нас его готовят неправильно.
После того, как мне пришлось влазить в исходники swagger и править там кусочек, что бы получить сгенеренный корректный код клиента, я решил, что не поленюсь руками код писать. По крайней мере это более предсказуемо по срокам.
Авторы интерфейса сказали "а мы swagger используем только для документирования и у нас проблем нет".
Уже не помню в чем там была проблема… года 2 назад было. Но осадочек остался.
Только ведь не важно что будет (swagger, WSDL и т.п.) если проблема в:
Перегенерация клиентов на любое изменение апи, ..., отсутствие поддержки предыдущих версий API
У нас приняты правила:
- мажорная версия АПИ в урле
- в рамках мажорной версии данной функции обратная совместимость обязательна
- параметры, которые добавляются в запросы в рамках минорных версий, не могут быть обязательными
- клиенты и серверы толерантны к данным, которые не оговорены в АПИ
Таким образом, из-за пункта 1 любое несовместимое изменение просто добавляется в версию выше по другому урлу. Плюс: клиентскую часть не требуется перегенерировать с выпученными глазами. Плюс: Не требуется проводить синхронных установок на ребочку и т.д.
Из-за пунктов 2 и 3, при поднятии минорной версии, клиентов не требуется перегенерировать, если им не требуется новые параметры. Плюс: можно продолжать работать на старых клиентах и всё должно работать.
Плюс: из-за пункта 4 любой из участников может обновиться независимо от других. Если у клиент не использует новые функции, то он может уехать на рабочку раньше сервера и это не сломает обмен. Может сервер уехать на рабочку раньше клиентов и новые параметры возвращаемых значений не сломают клиента.
Из минусов:
- программистам работать (а точнее думать) приходится.
Надо держать совместимость старых версий до какого-то срока (обычно полгода-год). Надо писать код, который не уйдёт в разнос, если появились какие-то данные или неожиданные возвращаемые значения. - нужна строгая дисциплина. Ну тут ревьюверы помогут, ибо если они пропустят изменение, нарушающее правила, то им же и придётся судорожно обновлять все системы
Очень умиляют такие обобщения.
Если не придется делать общий пул или держать несколько клиентов, то можно попробовать Unirest, это обертка над apache http components.
Но у него есть два существенных минуса:
- Все написано на статиках с единственным экземпляром синхронного и асинхронного клиента.
- Долгое время не обновлялся.
Для решения этих проблем существует форк с объектным стилем, однако если они появятся, то проще обернуть http client самому.
Немного в сторону: если кому надо SOAP дергать, вместо тяжелых Apache CXF и JAX-WS пригодится очень лайтовая библиотечка: https://github.com/reficio/soap-ws
Старые песни о главном. Java и исходящие запросы