I'll half-agree and half-disagree with other comments, I think. First, I think this is a clever way to wrap API requests in what strikes me as the modern PHP s

I'll half-agree and half-disagree with other comments, I think. First, I think this is a clever way to wrap API requests in what strikes me as the modern PHP style, which these days seem to largely driven by the de facto standards of PHP-FIG in general and Laravel and Symfony in particular. Use a CLI tool to generate a class that extends your base class and adds configuration, extend that class to build new more granular methods, maybe make a static facade to call everything. This is just super Laravel-ish and absolutely what I expect from modern PHP apps in 2021. Second, it is overengineered, because that is what modern PHP apps do. Spend a bit of time tracing just how much goes into encapsulating a PSR-7-compliant request, and think about how often code that's using those requests literally doesn't need anything more than the $REQUEST superglobal. (Gasp! They said "global!" Think of the children!) It's great to have standards for packages, but it seems like I'm spending way, way more time -- and occasionally writing more actual code -- figuring out how to do things The Right Way (tm). In the argument for Laravel Transporter, Mr. McDougall shows a bit of pretty clear code and then says, "But, this is very procedural." I mean, yes? It's kind of a procedure? "What happens if the URL changes? What happens if the query parameters change?" If I was insistent on wrapping this up in a class, I'd probably just write an API class that you call with something like $api = new FooApi(); $todo = $api->getCompletedTodos(); // or if I am feeling all static $todo = Api::getCompletedTodos(); and if the URL changes or the query parameters change, I still basically only have one place to change it. I'm not saying I pine for the days of 100% Procedural All Pasta All The Time. I'm just wondering whether maybe PHP developers should spend some more time with languages that not only aren't PHP, but aren't Java, then come back to PHP -- and start questioning the orthodoxy a little.