Use at least C++11 and the thread and mutex types in the standard library become available. Of if you must use C++03, use boost for these. There's not a good reason to reinvent those wheels.
Importing names (`using std::vector`, etc.) at the global scope in a header is not a great idea. You likely won't get burned by it as a library author, but the people wanting to use your library will, eventually.
I like the simplicity of approach for the http_request and http_response types. Many libraries try to provide type safety (i.e., a way to define a UserLoginRequest), but this is best left to a higher level library, in my opinion.
Don't name your enums WITH_ALL_CAPS. Those sorts of names often get smashed by the preprocessor. Given enough use, your library will eventually have a name collision there. I prefer using 'enum class' enums from C++11 and normal variable names. The enum class syntax forces the name to be scoped, so you don't have to worry about ambiguity or name collisions (provided you don't use YELLING_CASE_NAMES). If you must use all caps for some reason, prefix with your almost-certainly-unique namespace, so something like RESTD_HTTP_STATUS_OK.
There is this very nice talk on building a C++ rest framework using functional programming concepts. I like the analytical approach to design, and really hope it becomes an open source library soon.
I sifted. It looks like somebody exploring concepts, sort of a "Hello, world!" for client/server applications using a well-known/popular meme ("REST").
The code seems reasonable enough for that, but would need significant additional work for something that isn't a toy or used in very restricted environments.
Speculation, but perhaps it was a reaction to the short, negative response. Clearly, you looked at it enough to note a lack of tests. Did you see anything you liked? Something you might find useful? It's likely not your intent, but one could have read your comment as dismissive and unnecessarily negative. Then again, it's hard to know definitively why someone downvotes.
As someone else pointed out, the first commit was 16 hours ago. Maybe a little early to be disappointed about a lack of tests? It might have been posted to HN earlier than the author wanted it to be widely known. Who knows?
I'm a big fan of tests myself. I'm also a big fan of pointing out positives as well as negatives, and keeping things in perspective. It's easy to tear down projects in their early days (hours!). Let's show a little support as well if we're pointing out flaws rather than doubling down on negativity.
Use at least C++11 and the thread and mutex types in the standard library become available. Of if you must use C++03, use boost for these. There's not a good reason to reinvent those wheels.
Importing names (`using std::vector`, etc.) at the global scope in a header is not a great idea. You likely won't get burned by it as a library author, but the people wanting to use your library will, eventually.
I like the simplicity of approach for the http_request and http_response types. Many libraries try to provide type safety (i.e., a way to define a UserLoginRequest), but this is best left to a higher level library, in my opinion.
Don't name your enums WITH_ALL_CAPS. Those sorts of names often get smashed by the preprocessor. Given enough use, your library will eventually have a name collision there. I prefer using 'enum class' enums from C++11 and normal variable names. The enum class syntax forces the name to be scoped, so you don't have to worry about ambiguity or name collisions (provided you don't use YELLING_CASE_NAMES). If you must use all caps for some reason, prefix with your almost-certainly-unique namespace, so something like RESTD_HTTP_STATUS_OK.