Re: [cpp-netlib] RESTful service ..multiple client requests

[Dean Michael Berris]

On Thu, Apr 5, 2012 at 10:50 AM, Mark <ma74...@gmail.com> wrote:
>
>
> Fairly new to cppnetlib so bear with me.
>
> Goal is to demonstrate invocation of RESTful web services based on
> client CRUD operation requests and provide responses.
>
> IOW server code will parse CRUD operation, call the appropriate
> service with input arguments.  Once services is complete the response
> will be provided to the client.
>
> Given multiple clients (assume 50) initating requests.  It's not clear
> to me how the io_service/thread requests combo will be handled.  IOW,
> it seems reasonable to have a thread and io_service for each client
> requests, but it's unclear to me how to achieve this?
>

Look at the HTTP server examples to see how to do this. The HTTP
servers are generally thread-safe and are designed to handle these
requests concurrently already. The concurrency of the handlers is up
to the implementer.

>
> An aside:  Dean Michael alluded to putting together a web service
> framework time permitting which I believe aligns with what I'm trying
> to do so i'm hopeful he'll find the time.
>

Please don't let my lack of time stop you from working on it. I'll be
happy to review your changes if you send pull requests to the official
repository.

Cheers

--
Dean Michael Berris
Technical Solutions Engineer
Google

[Mark]

On Apr 4, 9:08 pm, Dean Michael Berris <dber...@google.com> wrote:
>
> Please don't let my lack of time stop you from working on it. I'll be
> happy to review your changes if you send pull requests to the official
> repository.
>

REST services framework question for you or anyone. I have not done
much in terms of web services implementation so bear with me. My
prime objective (hope-may not get there) is to stand up cpp-netlib as
an alternate implementation to an implementation that's framed
around:

Apache Http Server <-> FastCGI <-> Web services (Java) where the
Apache HTTP Server and Web services are running on separate machines.

After some thought I'm struggling to understand the RESTful design
considerations surrounding cpp-netlib, specifically
a) The gateway implementation which I suspect would be part of the
cppnetlib HTTP server?
b) How would the gateway implementation extend to web services
assuming separation between gateway interface and HTTP server? In
other words, from a web service perspective a developer will need a
GGI frontend for their web service. If the GGI implementaiton is
bundled with the HTTP server there's no 'reuse'. Of course there's
alternatives such as ( (assuming C++) fastcgi++ or some variant but
personally I'd like to stick with one library.

Thanks
Mark

[Dean Michael Berris]

On Thu, Apr 26, 2012 at 7:41 AM, Mark <ma74...@gmail.com> wrote:
>
>
> On Apr 4, 9:08 pm, Dean Michael Berris <dber...@google.com> wrote:
>>
>> Please don't let my lack of time stop you from working on it. I'll be
>> happy to review your changes if you send pull requests to the official
>> repository.
>>
>
> REST services framework question for you or anyone.   I have not done
> much in terms of web services implementation so bear with me.  My
> prime objective (hope-may not get there) is to stand up cpp-netlib as
> an alternate implementation to an implementation that's framed
> around:
>
> Apache Http Server <-> FastCGI <-> Web services (Java)  where the
> Apache HTTP Server and Web services are running on separate machines.
>

Interesting.

> After some thought I'm struggling to understand the RESTful design
> considerations surrounding cpp-netlib, specifically
> a) The gateway implementation which I suspect would be part of the
> cppnetlib HTTP server?

Nope, you have to write that on your own by either:

1. Implementing the FastCGI protocol over TCP.
2. Implementing a reverse proxy.

> b) How would the gateway implementation extend to web services
> assuming separation between gateway interface and HTTP server?  In
> other words, from a web service perspective a developer will need a
> GGI frontend for their web service.  If the GGI implementaiton is
> bundled with the HTTP server there's no 'reuse'.   Of course there's
> alternatives such  as ( (assuming C++)  fastcgi++ or some variant but
> personally I'd like to stick with one library.

Unfortunately FastCGI is completely separate from HTTP. I don't think
implementing the FastCGI protocol is a bad idea -- that makes running
existing FastCGI binaries/modules easier to integrate.

However I was thinking more when I hear "web service framework" of
something that makes it easier to actually just implement handlers
using OOP, similar to how you write Java Servlets. Infrastructure like
reverse proxies and similar things already exist and although you can
implement those with the building blocks in cpp-netlib, the framework
idea actually implementing the business logic in C++ instead of a
scripting language or Java is the crux of the matter.