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