What web server interface to choose?

Question

I'm in the process of planning a web service, which will be written in C++. The goal is to be able to select more or less any web server to drive the service. For this to become true, I obviously have to choose a standardized interface between web servers and applications.

Well known methods that I've heard of are:

• CGI
• FastCGI
• WSGI

Now, as I have absolutely no experience on using those interfaces, I don't really know what to choose. I do have some requirements though.

• needs to be reasonably fast (from what I've heard of, this pretty much rules out CGI)
• should be easily usable in a pure C/C++ environment (e.g. there should be libraries available)
• must provide support for HTTP 1.1 (dunno if that matters)

Thanks for any suggestions :)

Answer 1

Why in the world c++ ?

CGI, FastCGI, and WSGI are pretty much the same thing implemented differently under the hood, the public interfaces should be the same.

If you insist on using c++ pick one of these I cant advice you on witch one.

But I really thing you should pick something easier to write your web service in. Most framework/languages allow you to escape to c/c++ to do the heavy lifting when necessary.

Answer 2

WSGI is for Python apps; if your language is C++ this isn't an option.

FCGI is a good way to go. An FCGI can be invoked as a standard CGI, convenient for debugging and testing, then run as an FCGI in production.

Performance of CGI vs. FCGI depends a lot on what you're trying to do and the amount of traffic you expect. Tasks that have a lot of startup overhead benefit most from FCGI; the FCGI controller can be configured to spawn additional processes to handle heavy loads.

Practically any web server will run CGI with minimal configuration; you'll likely need an additional module to run FCGI but that depends on the web server.

http://en.wikipedia.org/wiki/FastCGI

Answer 3

there is nothing "slow" about CGI it just isn't scalable. FCGI is more scalable but you can't easily develop in that environment because the process is long lived and makes debugging a nightmare. HTTP/1.1 isn't an issue at this level of abstraction. If you are worried about speed and at this point without any profiling or testing you shouldn't be, but these interfaces are not about speed they are about compatibility. Speed will depend on the container you are running your code from.

Answer 4

there shouldnt be much problems with CGI/fastCGI. if you implement fastcgi, your program can still run as normal CGI. and most web servers support cgi/fastcgi.