Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127772
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 27 Jun 2025 09:37:28 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a28aeb03-a8c8-40d8-a3fd-14c60f1ab9f7@app.fastmail.com>
In-Reply-To: 
 <CA+NMNO3DyYQSi6M4BwhbBhocu=2ToA5=6ZLYiQ5oXr1sUj7E5w@mail.gmail.com>
References: 
 <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <22a4327d-b27d-4e24-b07a-ae380fe8a0c4@app.fastmail.com>
 <efe58859-aa50-4cff-ad80-93712e1cc88f@rwec.co.uk>
 <CA+NMNO3DyYQSi6M4BwhbBhocu=2ToA5=6ZLYiQ5oXr1sUj7E5w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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