RESTinio: небольшая header-only библиотка для асинхронного REST API на C++

Дело-то благородное, только REST не подходит для запросов, которые занимают целые секунды. Тут уже нужна асинхронность и вебсокеты.

А что вы понимаете под асинхронностью?

У нас был сценарий, когда получив запрос, нужно обратится в ряд подсистем для получения данных необходимых для ответа. И чаще всего это не занимает много времени, но эпизодически ответ от других подсистем может идти долго (например на БД был ребилд индекса и запросы связанные с ним на это время начаинают тупить), но чтобы такой запрос не забирал много ресурсов, например нить, нужно чтобы запрос можно было получить и передать куда-нибудь, откуда потом уже будет создан ответ. Вот такая асинхронность нам и была нужна в первую очередь. И такую асинхронность RESTinio нам дает.

eao197 перелогинтесь

В этом проекте я так, просто сбоку постоял немного. Тему же создал как раз таки автор и основной разработчик.

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

Я не привык придираться ко всем подряд, в отличии от.

Ответ на удаленное сообщение tailgunner: Asio не является препятствием к использованию C-шной реализации http-парсера из NodeJS. Соответственно, не видно причин по которым Asio мешала бы использовать PicoHttpParser. Если это, действительно, кому-то интересно, то можем поставить в roadmap.

Для меня само использование Asio является препятствием.

Думаю, для тебя еще большим препятствованием станет то, что это C++14 only библиотека, мы даже на поддержку C++11 в ней не заморачиваемся.

само использование Asio является препятствием.

А что в ней? этож тупая обертка над epoll или kqueue и этим как его .. в венде который.

Библиотека небольшая - ради С++11 еще можно было бы попробовать поработать топором. Но с Asio пытаться бесполезно.

само использование Asio является препятствием.

А что в ней? этож тупая обертка над epoll

Тупая? Ну-ну.

Так а чем тебя Asio смущает? Не можешь ее в свой проект затащить?

Ну и вдогонку, если не Asio, то какие низкоуровневые реализации работы с сетью тебя устраивают? libuv, libev, libevent, ...

Тупая? Ну-ну.

то есть просто ниасилил. Ясн.

В этом проекте я так, просто сбоку постоял немного.

С ведерком попкорна?

С ведерком попкорна?

С поджопникораздавателем :)

Так а чем тебя Asio смущает? Не можешь ее в свой проект затащить?

По разным причинам, я ограничен стандартными библиотеками Си/Си++ и старым компилятором.

какие низкоуровневые реализации работы с сетью тебя устраивают? libuv, libev, libevent, ...

Голый poll или epoll или абстракция над ними, не тянущая за собой Asio или даже libev (ага, я понимаю, что это не нужно никому, кроме меня).

я ограничен стандартными библиотеками Си/Си++ и старым компилятором.

А ты точно уверен, что standalone версия Asio не работает на твоих старых компиляторах?

А ты точно уверен, что standalone версия Asio не работает на твоих старых компиляторах?

http://stackoverflow.com/questions/24877233/header-only-asio-standalone

«Thus even when ASIO_STANDALONE is defined, Asio will use Boost when:

Using a non-C++11 compiler.
When using certain features, such as stackful coroutines that are based on the Boost.Coroutine library.»

Кроме того, мне интересен REST, но не особо нужна асинхронность.

Кроме того, мне интересен REST, но не особо нужна асинхронность.

Тогда тебе имеет смысл смотреть в сторону какого-нибудь civetweb-а.

Тогда тебе имеет смысл смотреть в сторону какого-нибудь civetweb-а.

Но это сервер (с самопальным HTTP-парсером, насколько я понимаю). А я заинтересован в маленьком клиенте, который работает с http-parser или picohttpparser. Т.е. что-то очень близкое к вашему restinio.

У picohttpparser, наверное, самый простой интерфейс, какой только можно придумать. Возьми его, да используй поверх «сырых» сокетов — че как не мужик-то?

Т.е. что-то очень близкое к вашему restinio.

В restinio сейчас только сервер, клиента там нет пока.

Я стараюсь не изобретать велосипедов, если могу этого избежать. А так - у меня уже есть http-parser поверх сырых сокетов на серверной стороне.

Упс. Значит, я был невнимателен.

Велосипедостроение же, https://github.com/splunk/pion - стабильный, по полной юзает ASIO, отвязывается от Boost на раз-два.

А хедер-онли - это такой гиммик - полезность только в обогреве помещения средствами i7 при компиляции.

отвязывается от Boost на раз-два

Так если отвязывается вручную, то разве не получается собственный велосипед, который не может просто так забирать свежие обновления из исходного pion-а?

https://github.com

не может просто так забирать свежие обновления из исходного pion-а?

на раз-два
git.

свежие обновления из исходного pion-а?

8 months ago
a year ago
3 years ago
5 years ago

на раз-два
git.

Т.е. сперва на раз-два в коде boost::mutex::scoped_lock меняется на std::lock_guard, потом делается мерж новых фрагментов из основной ветки pion-а и на раз-два делаются аналогичные замены в новом коде.

Вы сами так делали?

Ты только что описал типовую командную разработку «своими словами».

1. Ровно для этой задачи git и предназначен.

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

2. Я (и еще тьма народу) так делаю последние лет 8-9.

Речь не об этом. Речь о том, зачем сперва тратить время на выпиливание Boost-а из текущей версии Pion-а, а затем еще тратить время на аналогичные операции при подтягивании апдейтов из Pion-а?

Речь не об этом.

Вообще-то речь была именно об этом:

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

Ненужность буста даже не обсуждалась.

Ненужность буста даже не обсуждалась.

Аноним выше сказал, что Pion на раз-два отвязывается от Boost-а. Как по мне, в результате отвязывания получается именно что еще один велосипед. И для забирания новых изменений из Pion-а нужно будет еще тратить время. Вопрос в том, зачем это нужно.

в результате отвязывания получается именно что еще один велосипед.

Ничего, что оригинал - это тоже велосипед?

Вопрос в том, зачем это нужно.

Множество возможных причин практически не ограничено, начиная с технических ограничений (см. посты tailgunner'а).

Меня удивляет сама постановка вопроса. Это как придти в автомастерскую и спросить «Чуваки, а нафига вы с машинами возитесь?».

Ничего, что оригинал - это тоже велосипед?

Аноним так явно не считает.

1. Не имеет значения.

2. В его посте идёт противопоставление создания велосипеда с нуля допиливанию под себя уже готового.

1. Не имеет значения.

Это ваше личное мнение.

2. В его посте идёт противопоставление создания велосипеда с нуля допиливанию под себя уже готового.

Я бы хотел узнать у анонима, в чем он видит смысл такого «допиливания» с учетом наличия уже существующих альтернатив Pion-у, не привязанных к Boost-у. Но тут приходите вы и... Что полезного вы сказали, простите?

Асинхронность и параллельность - разные вещи.

А что значит header-only?

Это значит, что сама библиотека представляет из себя только заголовочные файлы. Единственное, что там нужно компилировать — это http-parser.

Объясните дураку, чем вызван этот фетиш хеадер онли?

А, т.е. код закрытый как таковой, но заголовочники есть, я правильно понимаю?

Я бы хотел узнать у анонима, в чем он видит смысл такого «допиливания» с учетом наличия уже существующих альтернатив Pion-у, не привязанных к Boost-у.

И какие силы зла мешали тебе задать этот вопрос?

Что полезного вы сказали, простите?

Ты - первый.

Нет.

1. В отсутствии де-юре стандарта на систему сборки в C++, header-only библиотеки гораздо проще использовать людям, которые предпочитают разные build tool-ы: кто-то любит GNU make, кто-то Ninja, кто-то qmake или qbs, кто-то CMake, кто-то premake и т.д. Если разработчик библиотеки сидит на каком-нибудь GYP, а пользователь — на qmake, то интеграция header-only библиотеки в проект пользователя не вызовет проблем.

2. Если библиотека активно использует шаблоны, то, скорее всего, она именно header-only и получится. Просто потому, что шаблоны в C++ естественным образом живут, в основном, именно в заголовочных файлах. А активное использование шаблонов дает возможность гибко настраивать код под нужные пользователю условия без run-time оверхеда, который возникает при использовании интерфейсов, наследования, фабрик и пр. вещей.

Нет. Весь код открыт. Весь код находится только в заголовочных файлах. Поэтому нет отдельной стадии трансляции в статическую (.a/.lib) или динамическую (.so/.dll) библиотеку.

Компиляция кода библиотеки происходит каждый раз, когда идет компиляция пользовательского кода, в котором библиотека используется.

И какие силы зла мешали тебе задать этот вопрос?

Отсутствие ответа от анонима, которому я задал первый вопрос. И да, интересует ответ от него, а не ваше мнение по этому поводу.

Если говорить о том, что RESTinio далеко не первая библиотека для создания REST сервисов на С++, то все-таки есть более яркие примеры, такие как https://github.com/Microsoft/cpprestsdk и https://github.com/Corvusoft/restbed . И в данный момент они более развиты, богаты функциональностью и готовы для применения в коммерческих проектах. Тут не о чем спорить. Но есть что объяснить.

Этот велосипед родился не на пустом месте. Для поддержки REST API в C++ проектах мы использовали различные сторонние решения, и множество еще пробовали. Пару лет назад главным недостатком для нас в имеющихся решениях для REST в C++ была невозможность обрабтывать запросы асинхронно, потому что API всех таких библиотек требовал определится с ответом внутри обработчика, т.е. по выходу из него требовалось чтобы ответ был. Сейчас уже, конечно, стало лучше (см. cpprestsdk, restbed и не только). Появилось несколько библиотек и фрэймоворков, которые не только позволяют обабатывать запросы асинхронно, но и всячески стимулируют именно к такой обработке. А не так давно в очередной раз перед нами встала задача сделать поддержку REST API в одном C++ проекте. И как это часто случается, данные необходимые для ответа на запросы не могут быть получены сразу или гарантировано в течении короткого времени, т.е. запросы хорошо бы обрабатывать асинхронно. И, несмотря на наличие готовых библиотек и фрэймоворков, мы все же решили начать делать свою (N+1)-ую библиотеку для REST на C++. И на это были свои причины. Мы выписали требования, которые точно бы хотели от такой библиотеки, а именно - возможность асинхронной обработки запросов, кросс-платформенностость, возможность трасировки происходящего внутри инфраструктуры библиотеки, контроль над контекстом в котором выполняется прием запросов и их обработка и, желательно, чтобы вся эта радость была реализована по средством только заголовочных файлов, С++11, а лучше С++14. Т.к. готовых решений удовлетворяющих этому списку не нашлось, мы и начали делать RESTinio.

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

Read-only mode?

Даже читаю только по извещениям. На работе завал.