On Feb 10, 2008, at 10:05 AM, David M. Lloyd wrote:
I think that this bit can be, and is, handled with URLs. I don't
see the advantage of adding complexity to the metaphor and, hence,
the API.
This isn't a metaphor, it's an API. Using a metaphor to help
conceptualize
what you're trying to accomplish can be helpful, but there's no
point in
carrying it any farther than that. Once you start rejecting an idea
because
it doesn't fit you metaphor, you've stepped over that line. To
properly
design a useful API, the only thing that matters are the functional
requirements (i.e., what usecases must the API support?).
We shall agreed to disagree here.
I fully understand the need for compelling use cases to drive the
API. A clean metaphor means a clean API. A great metaphor helps
users quickly and accurately assimilate an API. Slavishly extending
an API in an ad hoc manner, and I'm not claiming that this is what you
are doing, to support use cases more often than not leads to a
Byzantine API that is hard to use. A good metaphor is very important.
In any case, yes, allowing the user to specify a URI to both a
connection
and a request would be sufficient to solve this problem. The key
difference
that I want to point out is, the request URI should not be required
to be
relative to the connection URI; consequently, the connection URI
should not
have a path, query, or fragment part (since the URI is used only for
the
purposes of extracting the scheme, host, and port). In addition,
the user-
info part should be part of the request URI (since it can change on a
per-request basis), not the connection URI.
The limitation on what would be allowed on a connection URI is the
reason
that I suggested earlier that the API could accept discrete scheme,
hostname,
and port parts - since the rest of the URI is not useful anyway.
But since
either method satisfies the requirements (it's just a question of
aesthetics
at this point), I'm satisfied either way.
I see and take your point. It is six of one and half a dozen of
another. What I'm confused about is why we need to initially specify
anything outside of the actual request. What problem are we trying to
solve? Maybe I'm misunderstanding what you are espousing so let me
put it in my own words and you tell me if it's accurate. Please
ignore the argument of using URIs or discrete parameters for me moment
because I think that they are obscuring my real concern.
HttpClient client = HttpClientFactory.create(baseURI);
client.send("/foo?pet=cat")
If this is accurate, I don't understand the need for the baseURI.
Maybe this is a MINA convention?
Regards,
Alan
