amphp / http-client-psr7 Goto Github PK

As for now, PsrAdapter class provides full set of methods to convert both Amp and PSR-7 requests and responses in both directions. There is an opinion that it could be split apart.

I think that most frequent use cases will consist of the following (maybe partially):

• Make call to PSR-7-compliant handler from Amp-compliant handler (this case will require toPsrRequest() and fromPsrResponse() methods):
  • convert Amp request it into PSR-7 request;
  • pass it to some code and get the PSR-7 response back;
  • convert it into Amp response and pass it further.
• Make call to Amp-compliant handler from PSR-7-compliant handler (this case will require fromPsrRequest() and toPsrResponse() methods):
  • Convert PSR-7 request into Amp request;
  • pass it to some code and get the Amp response back;
  • convert it into PSR-7 response and pass it further.

But, on the other hand, there are cases where "alien" code just alters messages and returns them back (adds headers, for example); in this case, we recieve the same class of object back, like this:

• convert Amp request into PSR-7 request;
• pass it to some code and get modified PSR-7 request back;
• convert PSR-7 request into Amp request.

This case requires toPsrRequest() and fromPsrRequest() methods, so I decided that splitting the adapter for the first group of cases can harm users that implement second group of cases and vice versa.

I've looked through @trowski 's implementation of server message bridge; it just implements MessageConverter interface that declares methods convertRequest() (that works like my toPsrRequest()) and convertResponse() (that works like my fromPsrResponse()). Thus, it allows only first use case.

@kelunik, what do you think about it?

Currently this package is not registered on Packagist so it can't be installed easily (ofc I can still add a vcs repo in my composer.json).