спасибо

спасибо

Кто ж его знает, сколько это времени займет, надо задачу оценивать в конкретной команде. Раз три человека сразу посоветовали, значит решение, как минимум, популярное и стоит его рассмотреть.

Да, я обратил внимание на количество людей) Отсюда и сформировался вопрос, как к людям, которые явно имели с этим дело.
Сейчас, раз уже одно из решений наклёвывается, я хочу сразу учесть хоть какой-то опыт внедрения, учась так сказать на чужих ошибках.
Хотя может с этим софтом и всё просто и я напрасно готовлюсь к проблемам, но самому мне это сейчас неочевидно

конторе 10 лет, они до сих пор API методы не описали до меня. хрен его знает почему, но вдруг причина была и я сразу опираюсь на то что с такими "причинами" мне придется работать. Разгребаю бардак

а сколько ендпоинтов и методов?

@DivineHelp, вам предложили 2 решения:

1. swagger - прикручивается к сервису (обычно очень быстро), документация генерируется автоматически, работает при запущенном сервисе - первое что вам поможет, сопротивление у более-менее адекватных разработчиков скорее всего будет минимальным

2. swagger (или OpenAPI) спецификация - пишется вручную (или генерится так же автоматически при старте приложения), стандарт описания контрактов проектирумого API, эффективно когда сервиса еще нет, а тесты/фронт на моках уже надо писать, заставить написать такую документацию разработчиков сложно (чисто по моему опыту)

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

ну вот я даже не распознал что решения два, а не одно. обратил на это внимание сейчас

со сваггером (1) понял
что касается 2го пункта: это ведь альтернатива первому? или "в дополнение?
второй способ имеет какое-то заметное преимущество над описанным в первом пункте, для случая когда сервис уже есть, как и фронт, а вот написание тестов это ближайшая перспектива и прежде их не было? Имеет ли также значение, что согласно стратегии, UI-тесты затем будут плотно опираться на написанные апи-тесты?

Java automation <> Penetration/security  testing как по мне все что надо знать )

Спасибо) большое)

1. Документация интерактивная, по сути еще один endpoint приложения, на котором поднят swagger ui с документацией. Трекать изменения API будет сложновато. Если кратко - описывает API «как есть».

2. Это файл со спецификацией, лежит в репозитории, по нему можно трекать изменения + большой набор тулзов, который работает с этой спецификацией - от генерации моков/тестов до валидации входящих запросов внутри самого сервиса. Кратко -  документ/соглашение «как должно быть»

спасибо!

А можете текстом? в личку можно. Но пока похоже на $.ProcedureID  и все

можете вот тут поиграться и подобрать выражение https://jsonpath.com/

вот пример надо взять первый  ProcedureID

да в личку можно

да и таких всязок много только с тазными ID

$.ProcedureID так не работает