Здравствуйте, Pauel, Вы писали:

НС>>>Оно и не должно. Потому что код на C# — первичен, а не наоборот.
P>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.
P>Спека генерируется обычно для внешних клиентов.
Ну вот тут

Автор: varenikAA
Дата: 07.09.20

сгенерировали. И клиентам пришлось пойти лесом. Добрые вы. Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.

P>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии. Там и rest-то не особо нужен. Можно просто описывать api в виде c#-либы. Это не code-first, а code-only. Т.к. отдельные спеки не нужны в принципе.

НС>>>Для любителей писать спеку openapi руками есть другие инструменты.
P>·>Какие?
P>Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.
Возможно. Я не видел для шарпа.

P>С опенапи есть
Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
В лучшем случае получается такая схема:

code1 + метаданные --[generator1]--> spec
spec --[generator2]--> code2

Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.

Схема должна быть проще:
spec --[generator1]--> code1
spec --[generator2]--> code2

И развешивать метаданные становится просто не нужно.

P>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
Это не проблема, это фича.

P>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.

Здравствуйте, Pauel, Вы писали:

НС>>>Оно и не должно. Потому что код на C# — первичен, а не наоборот.
P>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.
P>Спека генерируется обычно для внешних клиентов.
Ну вот тут

Автор: varenikAA
Дата: 07.09.20

сгенерировали. И клиентам пришлось пойти лесом. Добрые вы. Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.

P>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.
Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии. Там и rest-то не особо нужен. Можно просто описывать api в виде c#-либы. Это не code-first, а code-only. Т.к. отдельные спеки не нужны в принципе.

НС>>>Для любителей писать спеку openapi руками есть другие инструменты.
P>·>Какие?
P>Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.
Возможно. Я не видел для шарпа.

P>С опенапи есть
Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
В лучшем случае получается такая схема:

code1 + метаданные --[generator1]--> spec
spec --[generator2]--> code2

Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
Ещё недостаток, что generator1 и generator2 очень разные. Т.к. первый должен уметь парсить язык метаданных и генерить и генерить язык спеки, а второй генератор должен уметь парсить язык спеки и генерить на желаемом языке программирования.

Схема должна быть проще:
spec --[generator1]--> code1
spec --[generator2]--> code2

И развешивать метаданные становится просто не нужно.
И генераторы примерно одинаковые — они оба могут одинаково парсить тот же язык спеки и отличаться только шаблонами генерации на желаемых языках программирования.

P>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
Это не проблема, это фича.

P>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.