Re: [cpp-netlib-devel] Comments about the HTTP client interface

[Dean M. B. <mik...@gm...>]

Hi Agustin,

Sorry this took a while. I spent an offline weekend, and only now am I
able to catch up on the Internet backlog. ;)

On Fri, Aug 29, 2008 at 1:59 PM, Agustín K-ballo Bergé
<kab...@ho...> wrote:
> Dean Michael Berris escribió:
>> 1. Encapsulating the 'method' into the http::request object.
>> 2. Making the client accept the method as a string.
>> 3. Using the "push" abstraction to convey the action.
>>
>> I decided against all three because:
>>
>> For #1:
>> - This puts undue burden to the request crafting aspect: it makes it
>> cumbersome to craft requests that you intend to re-use anyway (perform
>> a HEAD first, and if headers don't fit a certain criteria then do a
>> GET using the same resource)
>> - It complicates the http::request implementation by deviating too
>> much from the message framework/abstraction
>>
> I would expect some orthogonality among the library. That is, if a
> client sends a request then I'd expect a server to be able to receive
> one. How could this be handled under the current design, in which the
> http 'method' is not part of the request?
>

Right. Actually, here's a little rationale on why the method is not
part of the actual request object:

1. The 'method' is important only as part of the action performed.
This is orthogonal from the message payload, which is the headers, the
destination (URI), and the source (undefined).

2. Encapsulating the 'method' from the actual *act* of _requesting_
keeps the semantics clear: given this message payload
(URI+headers+body) perform a GET|POST|HEAD|PUT|DELETE with this
payload.

> According to RFC2616, "A request message from a client to a server
> includes, within the first line of that message, the method to be
> applied to the resource, (...)". I would like to see a clear
> compile-time mapping for the objects, just as I like them for HTTP
> 'methods'. Perhaps something like this:
>
>    using namespace boost::network;
>    http::resource resource("http://www.boost.org/");
>    http::request request_;
>    http::client client_;
>    http::response response_;
>    request_ = http::get(resource);
>    response_ = client_.request(request_);
>
> IMHO, not only the code looks closer to the protocol, but also detaches
> it from the underlaying transport mechanism (client_ here). It may just
> be that this is not what the library seeks for.
>

Right. However:

1. The aim of the library is to make it simple; the HTTP protocol is
by no means simple and thus certain semantics need to be introduced to
make it simpler (i.e. decouple the message payload from the actual act
of requesting).

2. The design does not encourage standalone functions that are very
hard to extend -- http::get(...) will have to return the correct
request object type given the type of the resource object. The builder
interface couples the builder as a nested type of the actual
http::request type you intend to use, making implementation and
extension easier and more deliberate -- that's easier to document as
well.

> I would appreciate some enlightening on the subject.

I can say more, but I hope this helps. :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.