Да, спасибо. Мы смотрели на подобные синтаксисы и, в каком-то смысле, вдохновлялись ими (в частности http-клиентом от JetBraines). Но, всё-таки, тут есть приниципиальная разница: у нас не синтаксис для запросов, а полноценный язык описания API-контракта. Тут и задача другая, и требования намного шире.
Ахаха)) Спасибо, это очень остроумно — засунуть схему на языке JSight в OpenAI, мы до такого еще не догадались! Интересно, что OpenAI понял синтаксис языка JSight, даже не обучаясь — это уже само по себе говорит об интуитивной понятности JSight.
Что касается генерации схемы по примерам реальных запросов — идея интересная, и даже стоит у нас в планах. Однако на практике возникают практически нерешаемые трудности. В реальных проектах часто используются такие каверзные штуки, как пользовательские типы, наследование типов, вариативность типов (когда в одном и том же месте могуть быть данные либо одного типа, либо другого), специфические требования (например, регулярные выражения). Искусственный интеллект или любой другой алгоритм не сможет определить эти вещи просто по внешнему виду запросов.
Вот, например, у нас на бекенде JSight Server имеет API, при этом для описания всего лишь одного запроса используется 35 пользовательских типов данных: https://editor.jsight.io/r/4B01Gjo/1
Разве машина сможет определить все эти типы самостоятельно?
Браво!
Спасибо за пожелание) Мы сами смеёмся про 15-ый стандарт)
Да, спасибо. Мы смотрели на подобные синтаксисы и, в каком-то смысле, вдохновлялись ими (в частности http-клиентом от JetBraines). Но, всё-таки, тут есть приниципиальная разница: у нас не синтаксис для запросов, а полноценный язык описания API-контракта. Тут и задача другая, и требования намного шире.
Вот вам пример с типизацией и внутренней рекурсией (у типа @user может быть друг, который тоже @user): https://editor.jsight.io/r/YjP52L2/1
Такую штуку ни один синтаксис запросов не опишет.
Ахаха)) Спасибо, это очень остроумно — засунуть схему на языке JSight в OpenAI, мы до такого еще не догадались! Интересно, что OpenAI понял синтаксис языка JSight, даже не обучаясь — это уже само по себе говорит об интуитивной понятности JSight.
Что касается генерации схемы по примерам реальных запросов — идея интересная, и даже стоит у нас в планах. Однако на практике возникают практически нерешаемые трудности. В реальных проектах часто используются такие каверзные штуки, как пользовательские типы, наследование типов, вариативность типов (когда в одном и том же месте могуть быть данные либо одного типа, либо другого), специфические требования (например, регулярные выражения). Искусственный интеллект или любой другой алгоритм не сможет определить эти вещи просто по внешнему виду запросов.
Вот, например, у нас на бекенде JSight Server имеет API, при этом для описания всего лишь одного запроса используется 35 пользовательских типов данных: https://editor.jsight.io/r/4B01Gjo/1
Разве машина сможет определить все эти типы самостоятельно?
Александр, ВВДТ)) FastAPI — отличный фреймворк. Если он вас устраивает, то ничего больше не нужно)
Спасибо, Александр) Поможете нам, если поставите звезду на гитхабе. https://github.com/jsightapi/online-editor-frontend
О, приятно слышать) Спасибо за поддержку)
Конечно, мы не из них) Это просто пример. По поводу семантики — мы очень запариваемся. Вот, например, как мучительно мы выбирали между `optional: true` и `required: false`: https://jsight.io/blog/convenience-or-habit-required-vs-optional