Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Здравствуйте, SkyDance, Вы писали:
A>>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
SD>Аналогичный вопрос был на StackOverflow.
Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
Здравствуйте, Alekzander, Вы писали:
A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Вот здесь говорится, что Swagger Codegen для C++ и серверной части поддерживает Pisctache и restbed. ХЗ насколько этой информации можно доверять, но можете посмотреть сами.
Здравствуйте, so5team, Вы писали:
S>Swagger Codegen для C++ и серверной части поддерживает Pisctache и restbed.
Спасибо большое.
А нет ли чего-нибудь менее универсального? Это, конечно, здорово, что я смогу в будущем из того же файла с описанием имплементировать сервер на PHP Но по опыту, за это придётся платить возможными проблемами с конкретным енд-поинтом (restbed'ом). Было бы лучше, если бы это был конкретный веб-сервер на C++ со специально для него написанными тулзами генерации, а не тулзы генерации подо всё на свете. И генерировать документацию мне не надо. И JS-клиент генерировать тоже.
Меня бы даже устроило что-нибудь совсем простенькое, если бы всё было сделано на макросах (названия методов и параметров превращались бы и в строки для веб-сервера, и в класс C++).
Здравствуйте, Alekzander, Вы писали:
A>А нет ли чего-нибудь менее универсального?
Не в курсе. Мне не доводилось слышать про генерацию обработчиков HTTP-точек входа для встраиваемого в C++ сервера. Вроде как большинству достаточно наличия аналога Express-JS и все.
Единственное, что у нас спрашивали (а мы как раз сделали в свое время встраиваемый в C++ HTTP-сервер), так это генерацию из Swagger-а для нашего сервера.
Из современного модного и молодежного посмотрите на drogon, oat++, реанимированный crow и userver. Это вроде бы то, что претендует на более-менее высокий уровень. Хотя в дополнению к этому еще три-четыре альтернативы можно назвать, но про генерацию стабов для сервера я не слышал
Здравствуйте, Alekzander, Вы писали:
A>Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
Это не ты окислился, это swagger окислился. Правильные ссылки
Здравствуйте, bnk, Вы писали:
A>>Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
bnk>Это не ты окислился, это swagger окислился. Правильные ссылки
bnk>https://www.openapis.org/
bnk>https://openapi-generator.tech/
оффтоп, но что меня поражает во всей этой вакханалии — для Ады они серверный генератор сделали, а для самого популярного языка программирования (JS/TS) — нет. Это как вообще?
Здравствуйте, so5team, Вы писали:
A>>А нет ли чего-нибудь менее универсального?
S>Не в курсе. Мне не доводилось слышать про генерацию обработчиков HTTP-точек входа для встраиваемого в C++ сервера. Вроде как большинству достаточно наличия аналога Express-JS и все.
Это из другого проекта, который пробрасывает плюсовую имплементацию API в JS. Так вот, хотелось бы то же самое, но на уровень веб-сервера. Как можно заметить, тут дублируются имена для регистрации и имплементации (уж не помню почему), но это легко лечится.
Вот это было бы идеально.
S>Из современного модного и молодежного посмотрите на drogon, oat++, реанимированный crow и userver. Это вроде бы то, что претендует на более-менее высокий уровень. Хотя в дополнению к этому еще три-четыре альтернативы можно назвать, но про генерацию стабов для сервера я не слышал
A>class Library : public Webserver<Library>
A>{
A>...
A> BEGIN_FUNCTION_MAP
A> FUNCTION_2("getModules", getModules)
A> FUNCTION_1("offerResult", offerResult)
A> FUNCTION_1("requestSearch", requestSearch)
A> FUNCTION_0("getUserName", getUserName)
A> END_FUNCTION_MAP
A> json::value getModules(json::value folder, json::value sort) const;
A> json::value offerResult(json::value result);
A> json::value requestSearch(json::value query);
A> json::value getUserName();
A>};
A>
Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
A>Судя по всему, придётся взять какой-нибудь Mongoose и напедалить FUNCTION_MAP самому.
Как человек, которому довелось работать в C++ном проекте с Си-ным CivetWeb, могу лишь заметить, что если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
Здравствуйте, so5team, Вы писали:
S>Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
Готового, то есть, нету?
S>если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
А в чём проблема? Я так не делал, но в одном проекте у нас использовался сишный sqlite, и, вроде, ничего страшного не случилось.
Здравствуйте, Alekzander, Вы писали:
S>>Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
A>Готового, то есть, нету?
У вас же в примере нужно не просто взять параметр №1 из query-string и отдать в обработчик, но еще и нужно этот параметр каким-то образом превратить в json::value, а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр. Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается. Может в userver есть какие-то вещи для превращения входящих значений в что-то нужное прикладному коду. Не знаю, здесь чукча не читатель.
S>>если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
A>А в чём проблема?
Как правило, в C++ных фреймворках уже есть все нужное для нормального управления ресурсами. Например, request передается в обработчик в виде shared_ptr, что позволяет безопасно с ним работать. Тогда как в чистом Си будут голые указатели по которым хрен поймешь владеющий ли он или нет, можно ли его сохранять, как его освобождать при сохранении и т.д., и т.п. Плюс в C++ном коде может быть больше основанных на типизации проверок и все это будет защищать о разных неприятных ошибок.
Но, бывают разработчики, которых чисто-Си-шные макароны не пугают, терпения и внимания у них с избытком.
Здравствуйте, so5team, Вы писали:
S>У вас же в примере нужно не просто взять параметр №1 из query-string и отдать в обработчик, но еще и нужно этот параметр каким-то образом превратить в json::value
Это был код из проекта, где в C++ приходило значение из скрипта, а движок скрипта ЗНАЛ, что это за тип (типизация хоть и динамическая, но строгая). Поэтому и json::value. Тут же надо аргумент выковыривать из запроса, поэтому, соответственно, ожидается просто строка. Ну, можно при маппинге (в макросах FUNCTION_N) задавать тип, к которому требуется приведение, и отдавать его в конструктор json::value. Или просто всегда делать вызовы TryParse() в конструкторе json::value, дабы определить тип. (Предполагается, что json::value — тип, идущий в комплекте с веб-сервером).
>а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр.
Разве? Клиент (в моём случае предполагается зашитый в ресурсы html + js) выполнит запрос. Что бы я ни вернул в json::value из функции-имплементации, оно уйдёт к клиенту — в соответствии с названием — как json-строка. Там нигде не нужен никакой кастомный content-type, только стандартный application/json.
>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции. Почему это не сделано? Я что-то неправильное и нетипичное хочу?
Здравствуйте, Alekzander, Вы писали:
>>а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр.
A>Разве? Клиент (в моём случае предполагается зашитый в ресурсы html + js) выполнит запрос. Что бы я ни вернул в json::value из функции-имплементации, оно уйдёт к клиенту — в соответствии с названием — как json-строка. Там нигде не нужен никакой кастомный content-type, только стандартный application/json.
Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?
>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
A>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.
Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?
Под термином "встраиваемый HTTP-сервер" или "встраиваемый C++ фреймворк" мной понимается HTTP-сервер, который встраивается в приложение. А не работает отдельно и общается с приложением через какой-то IPC.
A>Почему это не сделано?
ХЗ, может и сделано. Мы в своем инструменте сделали то, что нам было нужно. И нет, нам такое было не нужно.
Подозреваю, что авторы других подобных инструментов сделали то, что было нужно им.
Уж простите, что не знаю возможности всех двух-трех десятков подобных библиотек для Си и C++.
vsb>оффтоп, но что меня поражает во всей этой вакханалии — для Ады они серверный генератор сделали, а для самого популярного языка программирования (JS/TS) — нет. Это как вообще?
Есть, конечно. Мы им даже пользуемся (typescript'овым).
Но по опыту, за это придётся платить возможными проблемами с конкретным енд-поинтом (restbed'ом). Было бы лучше, если бы это был конкретный веб-сервер на C++ со специально для него написанными тулзами генерации, а не тулзы генерации подо всё на свете. И генерировать документацию мне не надо. И JS-клиент генерировать тоже.
