Сервис на С с поддержкой OpenAPI

Why so sirius?

Разверни вопрос.

Он, вероятно, намекает, что язык выбран крайне подходящий для работы с вебом 🤭

Плохо искал: https://openapi-generator.tech/docs/generators/c

Посмотрел в википедии что такое этот openapi, оказалось что это спецификация для взаимодействия непонятно чего с непонятно чем. Ты уверен что оно тебе нужно? Мне кажется лучше задачу поконкретнее сформулировать.

Спасибо, пойду разбираться.

Ну, собственно, остался вопрос: насколько юзабелен http сервер на встроенном в libevent функционале.

Нет, остался вопрос зачем тебе это нужно.

Не буду оспаривать, но мне надо на C.

Интерес к реализации именно на C, опыт, нет желания тащить что-то вроде nodejs, java, etc…

Зачем C - понятно. Вопрос был про «зачем openapi».

OpenAPI это обычный JSON/YAML. Соответственно, тебе нужно просто посмотреть какие либы есть для C для парсинга этих форматов. И если очень хочется ещё нагенерить DTOшек, чтобы не выдёргивать данные по строковым ключам напрямую каждый раз из распарсенного JSON дерева.

Но я с трудом могу представить себе сервис, которому нужно именно в рантайме парсить OpenAPI, если только это не какой-нибудь визуализатор документации (и почему нельзя просто взять готовый Swagger UI).

Обычно OpenAPI пишут руками и генерируют из него код обработки эндпонйтов (тогда тебе нужен openapi-generator, который имеет поддержку генерации кода на C), либо генерируют спецификацию из кода. Но для этого надо чтобы код был на каком-нибудь навороченном фреймворке типа Spring умеющем в рантайм рефлексию эндпойнтов. Для С таких фреймворков вроде нет.

Относительно назначения, OpenAPI рассматривается как универсальный интерфейс для пользователей (клиентов) по взаимодействию с сервисами (серверами). Если спроектирована спецификация для некоторого сервиса, то на её основании можно генерировать исходный код для библиотек клиентских приложений, текстовую документацию для пользователей, варианты тестирования и др. Для этих действий имеется большой набор инструментов для различных языков программирования и платформ[3][2].

OpenAPI - машиночитаемый формат документации. Обычно конечные сервисы с ним не работают, с ним работают всякие туллинги типа кодогенераторов, визуализаторов документации (типа Swagger UI). Максимум OpenAPI в рантайме - его генератор из аннотаций эндпойнтов во фреймворках и языках с развитой рефлексией. Си здесь не очень хорошо подходит. Если тебе нужен веб-фреймворк с рефлексией на каждый чих, возьми что-нибудь на джаве. Либо ОП пишет тулинг для разработки сервисов, либо ему нужен один из вариантов openapi-generator для С (чтобы сгенерировать из готовой спецификации шаблонный код сервиса, а потом написать реализацию), либо ему не нужен OpenAPI.

Эту графоманию я и в википедии прочитал уже. Из неё совершенно непонятно, зачем он нужен. Какой-то сферический интерфейс в вакууме, несвязанный ни с одной из практических задач.

Обычно OpenAPI пишут руками и генерируют из него код обработки эндпонйтов

Вот это надо. Вернее для сервиса нужен именно код обработки, просто я решил разобраться, как с этим всем в С работать.

Ну а про libevent кто-то что-то скажет? годится его http для построения на нем сервиса?

Всё зависит от того что ты хочешь сделать. Поскольку ты кроме каких-то сферических целей ничего не заявил то сказать ничего нельзя.

libevent обычно избыточен, он заменяется парой страниц кода.

Из неё совершенно непонятно, зачем он нужен.

Попробуйте перечитать ещё раз.

Выглядишь глупо. Почти как противники статический типизации.

Не интерфейс, а кроссязыковое описание интерфейса.

Т.е. можешь делать велосипеды в своей вики в формате: у нас тут такие-то эндпоинты, поддерживают такие-то HTTP-методы, с таким-то форматом JSON и т.п., а можешь клиентам отдать OpenAPI-спецификацию и они сгенерируют клиентскую либу под себя, на удобном им языке, и меньше времени потратят на интеграцию с твоим сервисом.

Если строить event-based http сервис или web морду к какому либо сервису много что из нее можно взять. Так что если либа для этого и избыточна, то не сильно.

Ладно, с ней сам разберусь.

ВСЕМ СПАСИБО ЗА ОТВЕТЫ!

Нет, остался вопрос зачем тебе это нужно.

OpenAPI нужен, чтобы автоматически проверять реализацию HTTP API на соответствие спекам и генерить лапшу кода сразу с нужными типами.

Всегда ваш Копетан.

Выглядишь глупо. Почти как противники статический типизации.

Кстати, нет ни одного исследования, которое бы доказывало эффективность статической типизации. Ну просто ноль. Как так вышло-то?

это аксиома

это аксиома

Эскобара?

нелестные отзывы о реализации http в libevent, но вдруг что-то изменилось с тех пор

На неё забили. Разработчик libevent советовал использовать libevhtp в связке с libevent.

«Код обработки» никто в своём уме сам не пишет. Его авто-генерят из спеков. Для этого весь этот OpenAPI собственно и затевался.

Возьми нгинкс, вряд ли что-то лучше напишешь. Бизнес логику можно на луа написать.

так, значит смотри, мы это юзаем и пилим уже довольно долго.

Тебе нужно написать генератор кода из openapi в C. Он будет генерировать какие-то конкретные файлы, ты их не будешь уже трогать руками.

Искать готовый генератор под libevent не нужно, больше времени потратишь, чем напишешь что-то кастомное. А вот взять валидатор JSON schema лучше готовый, это муторная штука.

Ссылку на мой доклад на хайлоаде я попозже скину, как его в паблик выложат.

OpenAPI нужен для того, чтобы люди могли договориться друг с другом, о том, какие где поля, как они передаются и т.п.

Rust.

Тебе нужно написать генератор кода из openapi в C. Он будет генерировать какие-то конкретные файлы, ты их не будешь уже трогать руками.

Вопрос. Написал в swagger-editor'e свою спецификацию OpenAPI, сгенерировал backend c++ & qt, а дальше мне надо реализовать конкретную логику для обозначенных в OpenAPI post и get запросах. Идею того, что сгенерированный код уже руками трогать не очень хорошо осознаю, но куда вставлять собственную логику обоаботки запросов? Этот момент совсем не понятен. Пока решил, что в *.cpp файлах с обработкой post и get запросов буду создавать свой объект, через который и буду всё обрабатывать. Дополнительного кода в сгенерированных файлах не много, но имеется. Если есть более правильный путь использования сгенерированого кода, направьте в том направлении

я знаю два подхода.

Перемешанный, я его видел ещё в 2005-м, когда в сгенерированный код включаются комментарии, между которыми последующая генерация кода аккуратно не трогает ничего, сохраняя его.

Раздельный — это когда сгенерируемые файлы вообще никак никогда не трогаются человеком, а в них вставляются вызовы к тому коду, который ты уже пишешь руками. Т.е. у тебя сгенерен код:

if (request.operation_id == "articles_list") {
  return articles_list(parse_query_string(request))
}

и вот твой articles_list уже должен взяться из твоего кода. Если ты не описал его, код не должен компилироваться.

Раздельный добавляет косвенности и лишнее звено (ах, пара наносекунд потерь, надо оптимизировать), но делает возможным раздельные коммиты: вот коммит сделанный роботом, а вот сделанный человеком. Радикально облегчает ревью.

Раздельный — это когда сгенерируемые файлы вообще никак никогда не трогаются человеком, а в них вставляются вызовы к тому коду, который ты уже пишешь руками.

Спасибо за ответ, у меня как раз что-то похожее

Генераторы оберток генерят сильно всратый код. Для сервисов на голангах и прочих питонах сойдет, но Си или C++ поганить использованием генерированного из swagger.yaml кода не стоит. Распиши swagger.yaml, чтоб хипстота его почитывала, а сам реализуй http сервер Си c epoll-ом, или на C++ с boost::asio.

Это выходит за рамки области применения языка Си, и других ассемблеров.

нет, так не будет работать.

Через месяц схема и код разойдутся и будет черти чего.

Правильнее написать руками генератор кода такой, который напишет ровно то, что ты и сам написал бы руками. Просто он это будет делать единообразно и гарантированно.

отчего же? ведь на C тоже надо писать сервера.

Не разбираюсь в OpenAPI, но если нужно слушать http и делать роутинг в коде C, то проще написать своё. Если нужна простая заготовка для перепиливания под себя, могу дать. Там если выкинуть многопоточность и вебсокеты, совсем мало будет. И никакого оверхеда :)

Идиотов мало, которые сервисы на си пишут. И даже на Go такое писать - оверхед. Проблема низкой производительности решается запуском кучи дополнительных инстансов и допокупкой серваков. Напиши свой сервис на любом другом языке, который ускорит разработку в 2-3 раза.

Rust.

Это на переписать.

решается запуском кучи дополнительных инстансов и допокупкой серваков

Знал бы ты, какая сейчас идёт грызня за то, кому достанутся старые HP, а кто на виснущих китайцах с кривыми рейдами запускаться будет..)

Спасибо. Но решил делать сам - свои скилы поднимать надо.

Ну, у меня так и получилось - я когда стал делать, нашел описания и примеры для разных участков - чтение из сокета, формат http протокола, формат работы через вебсокет. Потом всё это обмозговал, добавил многопоточность и перехват BROKEN_PIPE. Мне очень помогла вот эта супер статья: https://istarik.ru/blog/programmirovanie/73.html