You might want to use CGI or FastCGI rather than an Apache module. You can
write CGI in any language, including C or C++ and there are libraries that
already implement FastCGI for both languages.
There are a few benefits of not using a module
- If you update Apache, you may need to make changes to the module, but you
shouldn't need to do that with CGI
- Any possible issue (security or otherwise) in your code won't affect the
whole server
- Your code will be portable to other web servers in case you ever decide
or are forced to switch

Other than that, your idea sounds great.

- Y


On Sun, Nov 29, 2015 at 8:12 AM, Torge Riedel <torgerie...@gmx.de> wrote:

> Dear list,
>
> I'm faced with the following "architecture" of an application:
>
> - Linux Server (small VM) with MySQL-DB, accessible via SSL from outside
> of the server, access is limited to a set of users
> - Client is a .NET-Application connecting to the DB with one user for each
> installation
>
> since this is not a very good architecture from several point of views I
> am thinking about changing it:
>
> - develop own Apache module offering REST services (one endpoint (resource
> part of url) for each operation)
> - use JSON as data format for GET/POST requests
> - let Apache handle SSL and authentication (authentication in the meaning
> of "general access" to the services)
> - manage permissions to protected data in DB and handle authentication to
> access this data by the new Apache module
>
> The decision to develop an Apache module instead of using Tomcat/Java is
> to avoid additional load on server, since Apache is already active. And I'm
> a C/C++ geek but not for Java. ;-)
>
> Questions to the list:
> - Am I one the right way?
> - Is there something missing from the security point of view?
> - Is there something pre-compiled for parsing JSON data in Apache modules
> (didn't find something, only Apache independent libs)
>
> Thanks in advance
> Torge
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

Reply via email to