On Thu, Mar 12, 2020 at 02:56:14PM -0700, Arthur A. Gleckler wrote:
> Still, type, URL, verb, HTTP version, headers, and timeout are included
> with every request. It seems cleaner to privilege them for that reason.
I agree. I would go so far as to separate out content as well, and if
it's non-#f, raise an error for the verbs that don't allow content.
You can do that whether you use a record or a dictionary. Anyway, between the two of you there is nothing left to put in the dictionary except the cookies field! Everything has become mandatory except that some things can be #f, which means they aren't really mandatory at all.
The advantage of having a dictionary is expansibility: an implementation can accept or ignore additional information without polluting the namespace with additional accessors. The advantage of putting *everything* in a dictionary is uniformity for the user: less API surface. You don't need a special constructor and accessors.
In addition, since users will normally construct request objects but not access their fields, a dictionary is easier to construct. If it's just an alist, quasiquote; if it's a hash table, the hash-table procedure (which accepts alternating keys and values), etc. Record constructors in Scheme are by order of arguments (aka "boa constructors"), which is hard to handle with more than a few components. So then we get to pointlessly mutable objects, and people reusing them badly, and general messiness.
Here's the current set of things (fields, keys, whatever) in a request: verb, url, headers, cookie-jar, connection-timeout, read-timeout, content. I got rid of file because I don't think uploading is a general enough use case client-side, though it's important server-side. Just open an input port on the file. So far the shape of a response remains the same.
I also realized that response-style makes no sense: it's the Content-Type header in the response that determines if what comes back is textual or not. I'm inclined to think that returning a bytevector makes the most sense, though I suppose some implementations might return strings if an explicit charset is specified or defaulted by the definition of that media type (as for application/json, which is UTF-8 by default). Still, it's easy to apply utf8->string, and something like 95% of all textual pages on the web today (per Google, which looks at what's actually there, not the content-type declaration) are UTF-8,
So here's my current notion of the simple API, when you don't need any real control at all.
(simple-http-request verb url [ content-type source ]) => bytevector
where source can be a bytevector, string, or input port.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgYou're a brave man! Go and break through the lines, and remember while
you're out there risking life and limb through shot and shell,
we'll be in here thinking what a sucker you are! --Rufus T. Firefly