Мне кажется, или там примерно то же самое?

там эта функциональность уже абстрагирована через дополнительный параметр, server_hostname

Там же не целые числа (11, 32), а с точкой или двумя (1.12.3, 3.22)
В этом то и проблема)

Так здесь то же самое, только отдельно host и port

ну в целом да, действительно
копну в эту сторону, спасибо

3.22 не подходит?
надо только все что от 3.2. ?

От 3.2.2, а таких же чисел нет в int

WHERE replaced::int > 3.2.2
Эта строка не работает, получается

а что-то вроде такого ?
SELECT number, substring(number, 3, 1) as find FROM
(select number from Testing WHERE number like '3.%')
GROUP BY find HAVING CAST(find as INT) > 2

Ребят, подскажите, пожалуйста, с такой проблемой:

Есть большое количество сервисов, в части из которых есть REST API, написанный с помощью Spring Web. Чаще всего этот API не публичный, но на него все равно должна быть документация, т.к. им пользуются ребята из поддержки.
Сейчас эта документация пишется вручную в двух местах: readme.md и в конфлюенсе. Естественно, при изменениях кода документацию частенько забывают поправить, либо правят только в одном месте.
Swagger есть, но он голый (без описания) и используется в основном поддержкой как UI для отправки запросов.
Мы сейчас думаем над тем, как можно сделать код единственным источником верной документации. Пока пришли к тому, что будем добавлять в контроллеры сваггеровские аннотации и по ним генерировать openapi.yaml.
От решения нам хотелось бы следующего:
1. Документация на сервис доступна для каждой релизной версии в любой момент времени (в идеале зашита в гите рядом с кодом самого сервиса).
2. Документация доступна, даже если сервис оффлайн.
3. Документацию можно посмотреть в человекочитаемом виде без лишних манипуляций.

С какими проблемами пока столкнулись:
- сваггеровский плагин для генерации openapi.yaml интегрирован только с JAX-RS и не работает со спринговыми контроллерами
- есть плагин springdoc-openapi-gradle-plugin, но он очень странно работает: Он поднимает все Spring Boot приложение, HTTP запросом выкачивает из него openapi.yaml, сохраняет его в файлик и гасит приложение. Хотелось бы, чтобы для генерации не нужно было поднимать апликуху, т.к. у нее может быть много зависимостей, которые придется чем-то мокать (БД, hazelcast, kafka и т.д.)
- Вызов тасочки плагина нужно как-то добавить в CI сборки релизной ветки так, чтобы сгенерированный openapi.yaml коммитился в репо. Я лох в devops'е и не знаю возможно ли такое реализовать
- Сгенерированные openapi.yaml нужно чем-то просматривать. Можно конечно порекомендовать сопровожденцам запихивать файлик в swagger editor, но это лишние действия, которые хотелось бы автоматизировать. Собственное приложение, которое сканирует все релизные ветки в репо, находит в них документацию, и обертывает это в красивый UI, писать лень, возможно существуют уже готовые решения. Помимо Swagger есть еще Redoc и Rapidoc, но как их затащить под свои нужды я пока не придумал

Может быть кто-то сталкивался с подобной задачей или решал часть из озвученных проблем. Поделитесь, пожалуйста, опытом

> 2. Документация доступна, даже если сервис оффлайн.

В IDEA нативно или плагином есть просмотр сваггера. Так что достаточно закоммитить (хоть автоматом в CI), и люди смогут смотреть.

У меня подход design first, так что у меня сначала появляется файл, потом сервис, потому что даже с ебучими аннотациями полностью задокументировать и прописать модели невозможно.

А еще можно в CI не коммитить, а выкатывать куда-нибудь на условный S3 и таким образом обеспечивать оффлайн-просмотр.

Необходимость иметь проект локально, иметь установленную идею, и открывать его постоянно - это очень больно, потому это так себе совет

Документация нужна по большей части для поддержки и для аналитиков, многие из которых не умеют пользоваться идеей

Так идея умеет открывать отдельный файл, не принадлежащий проекту, нет? достаточно гитом выгружать и иметь проект на один сторонний файл

Но да, это может быть не самым удобным способом

Осталось попросить продакт-менеджеров разного рода поставить всех себе идею

Про S3 интересная идея, а что делать, если у тебя не облако? Есть ли аналогичные решения, которые можно у себя развернуть?

Продакт-менеджеры смотрят спеку апи?

Они могут использовать её для демонстрации чего-нибудь легко, например

Да хоть minio или файл за nginx, который через scp копируется