基本上做 Web 开发需要的功能,比如 json ,静态文件,form ,Cookie 都支持的比较完整。而且还是一个纯异步的 web 引擎,性能相当可观。
#include "wfrest/HttpServer.h"
using namespace wfrest;

int main()
{
HttpServer svr;

// curl -v ip:port/hello
svr.GET("/hello", [](const HttpReq req, HttpResp resp)
{
resp->String("world\n");
});
// curl -v ip:port/data
svr.GET("/data", [](const HttpReq req, HttpResp resp)
{
std::string str = "Hello world";
resp->String(std::move(str));
});

// curl -v ip:port/post -d 'post hello world'
svr.POST("/post", [](const HttpReq req, HttpResp resp)
{
// reference, no copy here
std::string& body = req->body();
fprintf(stderr, "post data : %s\n", body.c_str());
});

if (svr.start(8888) == 0)
{
getchar();
svr.stop();
} else
{
fprintf(stderr, "Cannot start server");
exit(1);
}
return 0;
}

项目地址: github.com/wfrest/wfrest

补充,框架是基于C++ Workflow开发的。弥补了 workflow 在 web 功能上的不足,同时性能上有保证。

我疯了用 C++ 写 RESTful

Qt 也有个,之前写过

工作还是不够饱和

不错不错。好像还是基于 sogou workflow 库的,也不算是 start from stratch 。

当你碰巧有一个 C++ 服务需要暴露简单的 API ,这东西就非常有用了。

假如这个 C++程序员不懂其它 web 开发语言,这是个好选择

c/cpp 服务需要 Web API 的,一律用 CGI ,简单省事,不用写这些东西折磨自己。

是什么想不开要拿 c++写 restful ?

不,如果这个 C++ 服务不是一个 CURD 服务呢?如果它本身是个像 redis 一样的多线程(有后台队列)的服务程序呢?不是那种来一个请求启动一个进程,而是一个常驻内存、用满整个服务器核心的 C++ 程序呢?

比如,写了个特殊领域的小型数据库。写了个特殊的调度程序。写了个常驻内存的( C++ 算法)服务程序,每个请求都要占用所有 CPU 并行计算,更多的请求进 C++ 内部的队列,一个一个处理。这种场景下真的很有用,就是要在 C++ 程序里面内嵌一个 HTTP API 。

你们多少有些按照自己的经验,小看了 C++ 程序的多样化。

还是有一些需要高性能的场合的。而且懂点 C++的,这个库用起来不比别的语言复杂。

而且在我描述的这些场景里面,用 C++ 实现不是因为 C++ 程序员不懂其他语言,而是从效率和实现难度上,用 C++ 内嵌 HTTP API 都是最优选择。包括算法的例子,可能算法需要读取数据,这一步延迟高,所以不得不常驻内存。把 C++ 编译成 Python 模块,可能还不如内嵌一个这个。反正处理的请求是相当简单的

只写脚本的是理解不了一个可执行程序不但有图形界面还有 HTTP 接口的

针对你说的“碰巧有一个 C++ 服务需要暴露简单的 API”,我觉得起个 CGI ,简单的 IPC 好过引入这么一大坨东西,太多无谓的复杂度了。

见过 MIPS 处理器的路由器里面,用 printf 输出 web 页面的。资源有限,又需要实现一些功能的场景,还是有很多的。

看了这贴,多少能理解为啥现在的 web ,呃,不知道如何形容,就说这么让人难受吧,更让人难受的是,他发展的趋势是朝着更让人难受的方向。

某些场景还是有用的

但是写 web 的话,std::string 就能把你搞的欲仙欲死(

之前用过,当作 electron 的子进程来执行,但是,这玩意是真麻烦,艹

还有一个叫 libhv

还有一个 header only 的 cpp-httplib ,但是纯同步的。

进来之前,我还以为楼主重新发现了 CROW: github.com/ipkn/crow
进来之后,才发现这是另一个轮子。

这很 C++ -:)

。。。不是,你是不能理解 C++ 需要对外提供服务嘛?

服务内核是完全独立的,外部需要一个 gui 去操纵这个服务。C++ 服务可能部署在 vps 或者阿里云或者 kubernetes 里面,gui 管理程序可能是 qt 或者 c# 写的。这种场景你给 c++ 一个 http 接口难道不是最优解嘛?

而且你起个 cgi ,你是每个请求都要启动一个 c++ 服务。但我说了,这个 c++ 服务就是独立的进程,nginx 那种基础设施,gui 或者 web app 才是外挂的管理程序。你是除了 web 开发那三板斧一点都不懂啊

轮子和轮子也是不一样的。

CGI 启动的进程当然不是 damon 主程序,这还用说吗,需要啥数据通过 IPC 拿。关键是这样能把 Web 相关的一系列复杂度都抽离出去,程序里不用引入协议、路由、tls 等等一堆东西,每连接一个进程也不用关心锁、内存泄漏等问题。这个库看起来“容易”并不代表“简单”,依赖庞大,出了问题 backtrace 加长一截,都是不必要的复杂度。
至于 nginx 那些怎么能一概而论,我回复的一直都是“碰巧有一个 c/cpp 服务需要暴露简单的 HTTP API”这个问题,像是提供 metrics 统计信息、提供 API 给前端面板等简单需求,不值当引入这些复杂度。

我的第一反应也是用 IPC 就可以了,或者用 zeromq ,都比这个 http 的服务要好得多

看了下代码,相对于 crow 这种全是模板的,这个 wfrest 代码更简单易读

阔怕.....我之前也想过用纯 C 写...结果写着写着放弃了太难了....后面用 Golang 挺顺手的......

CGI 早就被淘汰了,不想自己处理 HTTP 相关的东西的话,现在也应该使用 FastCGI 了。目前似乎就只有 PHP 还是传统 CGI 那种从头执行到尾结束的模式了。

不,一个是只要部署一个 C++ 程序,另一个是还要配合一个转接 zeromq 的 cgi 程序 + ipc ,到底哪个复杂,你还要杠嘛?

这个可能还是要看个人口味了。如果让我选,我可能选 crow ,因为它是 header-only 的。当然 wfrest 也有别的优势 -:)

给用户部署的话当然是单程序集成了更“容易”。IPC 具体要看情况,比如给一个服务实现一个动态加载配置文件的 post 接口,直接把内容写到配置文件然后 SIGHUP 就可以;比如给 redis-server 实现统计 API ,直接用 redis client 就可以;比如给内核模块写个监控 API ,暴露个 procfs 就可以;再比如写个运维面板,和 systemd 等服务直接通过 dbus 就可以。总之很多情况,用 signal 、文件、pipe 、socket 等简单方式,或易集成的或已有的专用协议、rpc 、message pass 等,都可以避免在主程序中引入 Web 相关的一系列复杂度的前提下满足需求。

c++写网页,我比程序先崩溃

你和那些 web 程序员讲 c++,很多人都不懂的..甚至还有人认为 c++过时的..他们用着 c++大神开发出来的语言,开发 web,然后说 c++过时..是不是很有趣?

对对对,上面一群没用过 C++ 的,在和我这个今年写了八万行 C++ 的人辩论,C++ 里面到底是内嵌一个 HTTP 服务器暴露给前端 /GUI 更方便,还是引入 IPC 用 CGI/FastCGI 暴露给前端更方便。笑死我了

好多年前,我接到一个任务,开发一个响应时间极低(具体多少现在忘了)的 web 服务,我就用 libevent 和 C++编写,效果很好:快、稳。

上面要用 CGI 的朋友,当碰到需要完成一个设备 web 时候,拿 CGI 去写几百上千个接口,还得配合前端的同事实现前后端分离,不知道是什么感觉。

这个不错,引入方便。最近在用 mongoose 和 httplib ,都有类似支持,不过都是同步的

9494 。但凡写过实际的 C++ 项目也不会说出用 IPC 作为方案的话来。C++ 用 IPC 比内嵌 HTTP 服务器容易?笑死我了,这还不如 CGI 呢。当然 CGI 也是脑残