PSR-7 Compliancy

[aschwin]

Hi,

Is, or will, this client be PSR-7 compliant?

[tcdent]

I don't really have any interest in moving the backend away from cURL because of the low level flexibility it offers. Additionally, I don't find the user-facing API of PSR-7 to be more intuitive than what I have developed here. One glaring issue is the re-use of keys in headers and query strings, which we're not able to do since we are using built-in arrays. Does that warrant wrapping every URL in an object? (I think not.) I'm definitely open to incorporating fixes for edge-cases like that, though they will follow an API style more conducive to this library.

Please do let me know if you have any suggestions for improvement. I'm not trying to stagnate development here, nor do I believe there should be any limitation to the functionality of this library; I do regularly asses wether uncommon use cases deserve incorporation via new code or just additional documentation.

[aschwin]

My colleague is using your library and I want to review the capabilities of this library before I take this into my own project. PSR-7 is not a hard requirement (for now), but I will assess your library some further before I make a choice.

Thanks for your reply though. I keep an eye on this.

[tcdent]

Hey @aschwin, just FYI I recently pushed a small update which fully supports the use of repeated headers and parameters, which is something this library didn't support from the PSR-7 spec (aside from syntax). I'll be merging it into the master branch soon.

https://github.com/tcdent/php-restclient/tree/multistatus

[fuzzy76]

Just came across this and realised another thing: A HTTP messaging interface and a REST client are two very different things. Ideally you'd separate concerns and make a REST client that is a wrapper around a HTTP messaging interface. So supporting PSR-7 and using a messaging interface implemented with cURL are not necessarily mutually exclusive. :)