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

S>Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?

Когда? Когда зарегистрированная функция из FUNCTION_MAP отработала? Я бы сделал так: в этот момент пусть он всегда проставляет application/json, а вот если функция с подходящим названием не найдена — вызывает универсальный обработчик, в котором я сам выберу нужный content-type. Как и полагается при работе с универсальным HTTP-сервером.

>>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.

A>>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.

S>Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?

А я такое разве говорил где-то? Я говорил, что это типичный юз-кейс по словам авторов Мангуста. А для такого юз-кейса логично сделать простой маппинг запросов на вызовы C++. Что нужно и мне (но по другой причине).

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

A>>Готового, то есть, нету?

SD>На С++ вообще довольно странно писать такие вещи, как Swagger/OpenAPI web server.

Мне, ещё раз, нужно сделать доступ к API C++-ной библиотеки через HTTPS. Задача в этом.

Просто я изначально предположил, что было бы удобно описать интерфейс на отдельном языке, а потом 1) сгенерировать из него плюсовый хедер и 2) скормить веб-серверу вместе с указателем на имплементацию. Наверное, именно поэтому мне и предложили Swagger/OpenAPI.

Теперь я думаю, что это была плохая идея. Хорошая идея — сделать классический function map, пример которого я привёл. Другой пример был в MFC. Да таких примеров много, на самом деле. Осталось найти пример в области веб-серверов, и задача будет решена.

A>Мне, ещё раз, нужно сделать доступ к API C++-ной библиотеки через HTTPS. Задача в этом.

Может, проще будет взять какой-нибудь Питон, C# или Java, и через него высунуть? А библиотеку подключить через FFI.

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

A>>Мне, ещё раз, нужно сделать доступ к API C++-ной библиотеки через HTTPS. Задача в этом.

SD>Может, проще будет взять какой-нибудь Питон, C# или Java, и через него высунуть? А библиотеку подключить через FFI.

По-моему, ещё проще руками написать FUNCTION_MAP. Если не найду готовый.

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

S>>Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?

A>Когда?

Это к вам вопрос: когда у вас появляется знание о том, в каком формате отдавать результат.
Задача встроенного HTTP-сервера принять запрос, отдать вам какой-то объект request с параметрами этого запроса, получить от вас какой-то объект response и затем корректно передать содержимое этого response клиенту.

HTTP-сервер понятия не имеет в какой момент у вас появляется response и когда вы этому response скажете какой тип данных в нем будет находиться.

A>Когда зарегистрированная функция из FUNCTION_MAP отработала?

Вы так носитесь с этим FUNCTION_MAP, что хочется спросить: а зачем она вам? У вас счет точек входа идет на сотни?

A>Я бы сделал так: в этот момент пусть он всегда проставляет application/json, а вот если функция с подходящим названием не найдена — вызывает универсальный обработчик, в котором я сам выберу нужный content-type. Как и полагается при работе с универсальным HTTP-сервером.

То, что вы описали не имеет отношения к "универсальному HTTP-серверу", т.к. универсальный HTTP-сервер должен позволить пользователю принимать/отдавать что угодно: хоть картинки, хоть видео-файлы, хоть XML, хоть json, хоть yaml, хоть черта лысого.

>>>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.

A>>>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.

S>>Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?

A>А я такое разве говорил где-то?

Ага. Выделил жирным в ваших же словах.

A>А для такого юз-кейса логично сделать простой маппинг запросов на вызовы C++.

Простой маппинг и делается, как-то так:

router->http_get( R"(/:id{\d}/:tag([a-z0-9]+)/:year(\d{4}))",
  [provider]( auto req, auto params ){
    provider->handle_get( req,
        restinio::cast_to<std::uint64_t>( params[ "id" ] ),
        restinio::cast_to<std::string>( params[ "tag" ] ),
        restinio::cast_to<short>( params[ "year" ] ) );
    // ...
  } );

И если у вас полдюжины-дюжина точек входа для API, то все это прекрасно работает и без условного FUNCTION_MAP.

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

S>Как человек, которому довелось работать в C++ном проекте с Си-ным CivetWeb, могу лишь заметить, что если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.

вот не соглашусь. Сам работал с mongoose в С++ проекте. Мне понравилось. Нет RAII, нет строгой типизации, но нет и исключений и поведение библиотеки более предсказуемое. В общем чистый спор о фломастерах.
Хотя когда я использовал mongoose я просто накидал свой С++ враппер над ним.

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

SP>Хотя когда я использовал mongoose я просто накидал свой С++ враппер над ним.

Ну вот это и есть ключевое. Удалось сделать нормальный C++ враппер, проблем, скорее всего не будет.
Не удалось и...

Тогда как взяв C++ную библиотеку (особенно что-то помоложе ACE или POCO ) этой задачи, скорее всего, не будет в принципе.

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

S>Вы так носитесь с этим FUNCTION_MAP, что хочется спросить: а зачем она вам? У вас счет точек входа идет на сотни?

Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.

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

A>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.

Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)

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

A>>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.

bnk>Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)

Что-то их подозрительно много

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

A>>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.

bnk>Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)

Так я, в целом, согласен.

Но в этой ветке речь идёт не про веб-сервера вообще, а про организацию веб-доступа к библиотеке.

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

A>Так я, в целом, согласен.
A>Но в этой ветке речь идёт не про веб-сервера вообще, а про организацию веб-доступа к библиотеке.

А CGI не вариант (ну т.е. просто консольное приложение)?
Или это все работает на какой-то железке?

Я бы выбрал что попроще выглядит из того что выше насоветовали.
Вот CROW вроде куда уж проще?

А чем обусловлена оценка -1?

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

bnk>Вот CROW вроде куда уж проще?

А говорили, что помёрла.

S>А чем обусловлена оценка -1?

Несогласием с вот этим заявлением:

Что-то их подозрительно много

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

S>>А чем обусловлена оценка -1?

SD>Несогласием с вот этим заявлением:
SD>

SD>Что-то их подозрительно много

И? Их мало? Или более чем много? Их вообще нет?

S>И? Их мало? Или более чем много? Их вообще нет?

Их мало. И ничего подозрительного в этом нет.

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

S>>И? Их мало? Или более чем много? Их вообще нет?

SD>Их мало. И ничего подозрительного в этом нет.

Как человек, немного причастный к теме, могу сходу перечислить такие инструменты как Boost.Beast, Drogon, oat++, CROW (реанимированный), Simple-Web-Server, Pistache, lithium (бывший silicon framework), restbed, proxygen, cpp-netlib (он же cpp-httplib), userver, POCO, restinio. Это все проекты с множеством звезд на GitHub-е, кучей пользователей и признаками жизни. И это только на C++, я не стал включать сюда чисто Си-шные аналоги. Плюс к тому на reddit-е раз в пару месяцев люди задают вопросы о разработке бэкендов на C++ и в комментариях перечисляют и то, что указано выше, и еще всякое разное.

Так что, как по мне, для C++, который вроде как к Web-у или бэкендам никаким боком, что-то не так уж и мало встраиваемых HTTP/WebSocket серверов. Это жеж не спроста же ж.

Но если для вас мало, то что тогда "много"?

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

A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.

Про userver уже написали. Не получается с ходу нагуглить решение, но где-то читал что можно grpc обернуть и получить обычноый rest api.
Может для ваших нужд хватит простого grpc сервера?

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

SaZ>Про userver уже написали. Не получается с ходу нагуглить решение, но где-то читал что можно grpc обернуть и получить обычноый rest api.
SaZ>Может для ваших нужд хватит простого grpc сервера?

Я про grpc ничего не знаю, а как будет выглядеть вызов со стороны клиента? Беглый обзор пока ответа не дал. Мне нужно в 95% случаев делать вызовы из браузера и очень желательно БЕЗ ВНЕШНИХ ЗАВИСИМОСТЕЙ (в виде JS-библиотек). (Сразу скажу, это потому, что там кастомный диалект ES — он POST-запросы поддерживает, а неадаптированные библиотеки нет). Получится?