Closed damianopetrungaro closed 6 years ago
@damianopetrungaro Thank you for the question. The (short) answer is: This lib targets PHP >= 7.1 with strict parameter and return type declarations. PSR-7 targets PHP >= 5.3 (mostly) without any of these. Furthermore the request interface for this lib requires getters for callbacks which are not present in the PSR-7 interface. So it would need an PSR-7-extended interface for the request methods. The PSR-7 response is mutable, the response of this lib isn't. And I don't see a reason to change that.
But I have to admit that I didn't try to implement the lib with PSR-7, so I'd be happy if you find the time to give it a shot, check if it brings any advantages compared to the current solution and provide a PR for a review.
Return type can be easily added to your implementation using the PSR too.
Anyway, you can rethink your implementation for a more standard way.
As you said you're open to PRs so we can spend some time on it :)
Looking forward to it! Thanks.
After I was using PSR-7 implementations for a while now, I can say that they are not a good fit here, because they are made for HTTP and the FastCGI communication of this library has much in common with HTTP but neither use it nor is 100% compatible to it.
As this issue is stale for 8 months now, I'll mark it as wontfix
and close it.
Anyway, if you see different arguments and have an implementation, feel free to provide PR.
I took a quick look, and I don't get why don't use an implementation of a PHP PSR for HTTP Request and Response?