Comments 9
Ух, ты объяснил почти каждую строчку, круто!
Что здесь хотелось бы увидеть: абстракт на один абзац, строк на 6 хотя бы. С описанием, что дано и какая задача. Что было, что стало.
Файлы лежат непонятно где и как, зависимости и конфиг в maven/gradle непонятно какие. Было бы круто сразу увидеть репозиторий на Гитхабе с минимальной демкой, по которому можно идти вместе со статьей и понимать написанное.
Все ссылки на отдельные строки можно было бы сделать ссылками на конкретные метки в GitHub. Гитхаб так может.
oneof инструкция корректно поддерживается? Заметил, что всякая дичь генерится для нее
Я б расширил этот вопрос и на anyOf с allOf...
OneOf, AnyOf, AllOf - поддерживаются, генерируются. Основная сложность - это понять предлагаемую концепцию и правильно написать спецификацию.
Если мы работает с event стилем моделей (когда в один эндпоинт приходит много моделей, которые различаются полями и идентифицируются по какому-нибудь eventType полю) - то только так и можно работать.
Сделаю отдельную статью с примерами
Подготовил небольшой пример: https://habr.com/ru/articles/774928/
Далее чтобы подключить серверную часть, нам необходимо создать свой контроллер, наследующий сгенерированный, и повесить аннотацию @Controller
Вот здесь хотелось бы пояснения (в идеале - вторую часть статьи). Дело в том, что если просто включить в свое приложение все сгенерированные таким образом классы и Spring-контекст, то подложить свой контроллер MySomeServiceApiController на указанный в OpenAPI url не получится - RequestMapping уже будет занят сгенерированным контроллером SomeServiceApiController.
Чтобы такого не получилось, придется не включать сгенерированный Spring-контекст, либо...
Либо использовать опцию delegatePattern=true. Тогда помимо SomeServiceApiи SomeServiceApiControllerбудет сгенирован делегат в виде интерфейса с дефолтными методамиSomeServiceApiDelegate. И как раз делегат можно создать уже свой.
Работа с делегатами обладает следующими преимуществами:
Java-код не содержит никакой логики работы с HTTP, весь HTTP-слой можно полностью взять из классов, сгенерированных по OpenAPI. Сохраняется IoC-структура приложения, ориентированного в первую очередь на OpenAPI
Заглушки попадают в конечный сервис, что удобно для тестирования, если за OpenAPI отвечают не те же люди, что за реализацию сервиса - просто поменяв API можно сразу после пересборки увидеть появившиеся endpoint'ы.
Добавил в статью пример, вот здесь можно посмотреть как подключить контроллер.
В статье и примере в контекст подключаются бины только feign клиентов.
Подключать сгенерированный контроллер в контекст не имеет смысла потому что там мы не можем ничего написать.
А зачем делать в репозитории с контрактом папку для каждой версии? Почему не обойтись тегом в гите?
Генерация контрактов OpenApi или прикладной API first: гайд по генерации в Spring Boot приложении