search

qenta-cee / checkout-client-library

Client library used mainly by QENTA Checkout Page and Seamless plugins for payment processing
GNU General Public License v2.0
6 stars 2 forks source link

Consider splitting off the message structure from the transport? #19

Closed judgej closed 5 years ago

judgej commented 7 years ago

Just wondering if this is something you would consider for this package.

The package contains the data structures (nestable objects) to support most or all of the Wirecard services. Those structures are transport agnostic - they do not care how they get sent to the gateway, and that makes them very useful and flexible to use across other libraries and packages.

However, this package is then locked down to a specific version of Guzzle. That restricts where it can be used due to this fixed dependency. I would like to suggest instead of making Guzzle mandatory, you just provide an interface for a HTTP client, so other clients can be used. composer can still list Guzzle as a recommended package and provide a connector for it, but it wouldn't be locked to requiring Guzzle to be installed.

What are your thoughts on this? My use-case is a platform that cannot use Guzzle 6.2, which means I cannot use this package at all. I can fork it and take out the Guzzle dependency, but there could be a more permanent solution that I can help with if I'm going to that effort in the first place.

reka commented 7 years ago

Thanks a lot, that sounds like a reasonable suggestion. We'll discuss it and get back to you next week.

reka commented 7 years ago

Thanks again for your very constructive suggestion, we've discussed it in the meantime. From the technical point of view it would be certainly a great improvement. Unfortunately we won't implement it in the near future, because our teams are focused on other products at the moment. Adding this change would also make necessary

Of course a pull request would be really appreciated.

judgej commented 5 years ago

Okay, thanks. I'm implementing API libraries using PSR-7/PSR-18/PSR-17 approach at the moment, and I mist say it is a pleasure to do. It keeps all the various layers of the process in separate and well defined, and allows additional decorators to be easily inserted, and alternative clients and message libraries to be swapped out. And of course, the generation of the PSR-7 models directly from OpenAPI 3.0 files. There are some really nice tools now to support this.