А при таком подходе как будут валидироваься входные параметры? Как кастовать например аннотации для валидации? (ну скажем сообщение об ошибке). Ведь код у нас уже сгенерирован
Валидация входящих параметров генерируется автоматом по спецификации (обязательность, тип данных, диапазон/enum). Класс ошибки тоже сгенерируется автоматом, если требуется его изменить, что-то новое добавить, то нужно сперва openapi схему поправить, затем автоматом класс ошибки станет требуемым. Тут речь про подход Api First, и подразумевается, что мы итеративно делаем сначала версию спецификации, затем код по ней. На выходе получаем, что реализация api в коде = документации (хотя тоже не всегда, можно иногда схитрить, но это тонкости). Я специально написал слово "итеративно", подразумевая, что может появиться новая версия спецификации, мы ее подкладываем в код, перегенерируем исходники, дорабатываем изменения в коде (новый эндпоинт или тип данных сменился)
Не знаю, смотрели ли вы пример исходников проекта, на всякий случай приложу ссылку github.com/MorkovkAs/openapi-example-toys-autogen Так как мы добавляем шаг генерации исходников при компиляции проекта, то любое изменение схемы влияет на генерируемые классы. Например, в первой версии спецификации Error состоит из 1 атрибута text. Будет сгенерирован класс с одним полем text. Мы будем где-то в коде его заполнять. Затем появляется вторая версия спецификации, где Error это 2 атрибута message и timestamp. При компиляции мы увидим, что старый код заполнения переменной text уже не валиден, надо заменить на message, + добавить заполнение timestamp. Как-то так:) попробуйте скачать мой проект и поиграться прям в нем с спецификацией и кодом, если что спрашивайте.
Ты говоришь, аналитик дает спеку. На новом рабочем месте встретился с тем, что используется этот подход и спеку вижу в джире. Я могу как-то ее стянуть, чтобы не описывать это всё ручками?
Все зависит от того, что именно у вас лежит в джире. Если прям спецификация в формате openapi, то считаем отлично. Копируем и вставляем в код. А вот если всякие таблички, списки, текстовое описание и тд, то не повезло. Придётся самому делать спеку в формате openapi. Для примера, мы в проекте четко разграничили зоны между аналитиком и разработчиком, когда речь про api. Никаких таблиц и текстовых описаний, только openapi руками аналитика, а дальше автоматом интерфейсы в коде.
ну, там как ui свагера это выглядит, с кнопочками try it out и schemas. В таком случае, я только ручками могу и только, так ведь? @@IT_like_bricks_building
@wunschpunsch77 Похоже на то, что за этим всем делом стоит сделанная спецификация. То есть она как файл существует скорее всего. Обычно, если это swagger ui или insomnia, то есть возможность скачать сам файл. Вот есть стандартный проект pets: petstore.swagger.io/ . Когда откроется swagger ui, то там сверху указана будет ссылка на скачивание самой спецификации: petstore.swagger.io/v2/swagger.json
спасибо
Первый комментарий от Васи) Звук бы немного побольше сделать.
Спасибо, учту:)
А при таком подходе как будут валидироваься входные параметры? Как кастовать например аннотации для валидации? (ну скажем сообщение об ошибке). Ведь код у нас уже сгенерирован
Валидация входящих параметров генерируется автоматом по спецификации (обязательность, тип данных, диапазон/enum).
Класс ошибки тоже сгенерируется автоматом, если требуется его изменить, что-то новое добавить, то нужно сперва openapi схему поправить, затем автоматом класс ошибки станет требуемым.
Тут речь про подход Api First, и подразумевается, что мы итеративно делаем сначала версию спецификации, затем код по ней. На выходе получаем, что реализация api в коде = документации (хотя тоже не всегда, можно иногда схитрить, но это тонкости). Я специально написал слово "итеративно", подразумевая, что может появиться новая версия спецификации, мы ее подкладываем в код, перегенерируем исходники, дорабатываем изменения в коде (новый эндпоинт или тип данных сменился)
@@IT_like_bricks_building Вы говорите что класс ошибки станет требуемым. А как это выглядит? Можете поделиться опытом?
Не знаю, смотрели ли вы пример исходников проекта, на всякий случай приложу ссылку github.com/MorkovkAs/openapi-example-toys-autogen
Так как мы добавляем шаг генерации исходников при компиляции проекта, то любое изменение схемы влияет на генерируемые классы.
Например, в первой версии спецификации Error состоит из 1 атрибута text. Будет сгенерирован класс с одним полем text. Мы будем где-то в коде его заполнять.
Затем появляется вторая версия спецификации, где Error это 2 атрибута message и timestamp. При компиляции мы увидим, что старый код заполнения переменной text уже не валиден, надо заменить на message, + добавить заполнение timestamp.
Как-то так:) попробуйте скачать мой проект и поиграться прям в нем с спецификацией и кодом, если что спрашивайте.
Ты говоришь, аналитик дает спеку. На новом рабочем месте встретился с тем, что используется этот подход и спеку вижу в джире. Я могу как-то ее стянуть, чтобы не описывать это всё ручками?
Все зависит от того, что именно у вас лежит в джире. Если прям спецификация в формате openapi, то считаем отлично. Копируем и вставляем в код.
А вот если всякие таблички, списки, текстовое описание и тд, то не повезло. Придётся самому делать спеку в формате openapi.
Для примера, мы в проекте четко разграничили зоны между аналитиком и разработчиком, когда речь про api. Никаких таблиц и текстовых описаний, только openapi руками аналитика, а дальше автоматом интерфейсы в коде.
ну, там как ui свагера это выглядит, с кнопочками try it out и schemas. В таком случае, я только ручками могу и только, так ведь?
@@IT_like_bricks_building
@wunschpunsch77
Похоже на то, что за этим всем делом стоит сделанная спецификация. То есть она как файл существует скорее всего. Обычно, если это swagger ui или insomnia, то есть возможность скачать сам файл.
Вот есть стандартный проект pets: petstore.swagger.io/ . Когда откроется swagger ui, то там сверху указана будет ссылка на скачивание самой спецификации: petstore.swagger.io/v2/swagger.json