Вот. Это я и хотел получить. Спасибо. Пойду писать плагин.
Хотя тут сложно. Например у krakend можно чейнить запросы. Как это отразить в open api непонятно. Аналогично и обратное. Например у krakend нет полей к примеру json а.
И наоборот из krakend генерить доку open api будет тоже сложно)))
Вот. Это я и хотел получить. Спасибо. Пойду писать плагин.
Хотя тут сложно. Например у krakend можно чейнить запросы. Как это отразить в open api непонятно. Аналогично и обратное. Например у krakend нет полей к примеру json а.
И наоборот из krakend генерить доку open api будет тоже сложно)))
ну я бы смотрел скорее в сторону генерации openapi из конфига кракена, так оно вроде проще а цепочки запросов и не нужно описывать в openapi, это же внутренняя реализация
Возможно не open api. В общем проблема в том что мне нужно как то документацию к api показывать. И нужно чтобы она точно была валидная.
Да. По этому я тоже думаю таким путем идти.
> В общем проблема в том что мне нужно как то документацию к api показывать. И нужно чтобы она точно была валидная.
не знаю подойдёт ли это в вашей конкретной ситуации, но GraphQL в этом силён. Схема GraphQL API и есть документация, при этом она жёстко привязана к коду
> В общем проблема в том что мне нужно как то документацию к api показывать. И нужно чтобы она точно была валидная.
не знаю подойдёт ли это в вашей конкретной ситуации, но GraphQL в этом силён. Схема GraphQL API и есть документация, при этом она жёстко привязана к коду
это не решит проблему с неконсистентностью между конфигурацией krakend и докой, более того кракен не поддерживает grpahql да и в принципе его никто не поддерживает)
это не решит проблему с неконсистентностью между конфигурацией krakend и докой, более того кракен не поддерживает grpahql да и в принципе его никто не поддерживает)
я не зря уточнил, что не уверен, подойдёт ли это в данной ситуации. Мне к сожалению не известен контекст