基本上做 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 也是脑残