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?). 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. - DML
