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

Reply via email to