On Thu, Jun 26, 2025, at 10:51 PM, Eric Norris wrote:
>> Adding more helpers in later versions is entirely trivial, but we could
>> set the precedent with a first batch on day one.
>
> I'm not opposed to this, but I am - as previously stated - nervous
> about how and where we draw this line, since I expect there may be a
> lot of opinions here. That said, if the general consensus is that we
> want direct methods or properties for the N most common use-cases, I'm
> happy to make that change to the RFC.
>
> I can try to take a look at the curl options and do some github
> searches to see if I can identify common patterns. I agree that
> setting the HTTP method and timeout are good contenders. If someone
> else wants to propose a list as well, feel free!
My gut sense is that the following use cases would cover the 80% case:
GET http://www.example.com/foo?bar=baz
(Send a GET request with a complex URL. Probably needs both transparent redirecting and not
options.)
POST http://www.example.com/foo
with a JSON body
(This means setting a body string/array, and a content-type header.)
POST http://www.example.com/foo
with a multipart/form-data body
(This means making it easy to set the body, and corresponding content-type header.)
And those should also allow setting an Accept header. Which means probably any header should be
easy to set, with maybe one or two extra-promoted ones. (Like, when setting the body you can also
set the content type?)
I don't know if specifying an HTTP version is relevant/useful. I have never done so myself,
but that proves little.
On the return side, I almost always check the status code, at least. That's probably the only
non-body thing I check. :-) So making that trivial is also important. Whether that's via a
mini-response object instead of a string or something else is open for discussion, I think.
Other questions:
* We have these shiny new URL/URI objects. Should those be supported directly?
--Larry Garfield