PSR-17 dependency

[atanvarno69]

In #41 @DaGhostman posted:

Has something like All about middleware been discuessed, more specifically the 3rd approach in section But What About Dependency Inversion???, which will obviously make this interface dependant on PSR-17?

Rather than clog up #41, it seems sensible to discuss the issue here.

To my mind there are a few approaches that work:

• Inject a factory (using the constructor or a setter, doesn't matter) into any middleware that needs the ability to return a response without further delegating or needs to modify the response body. If a StreamFactoryInterface is injected, get the response as usual from the delegate, build a new response body (optionally using the extant response body as a starting point) with the factory, do $response = $response->withBody($newBody); optionally fiddle about with the headers and return it.

  Or you can inject a response factory, and don't have to depend on getting your response instance from the delegate, which is better if you're building an error response.

  This method works with PSR-15 as is. No need for it to be dependent on PSR-17.

• As above, but inject a concrete instance of a (response with a) readable/seekable/writable stream. I do this at the moment. It does have a couple of drawbacks. You have to check the stream is readable/seekable/writable manually. This is what I'm doing currently, so I can type hint against ResponseInterface. When PSR-17 gets accepted, I'll switch to the above method, type hinting on the factory interface. Both work fine with your DI container of choice.

• Alter DelegateInterface to provide a stream factory and/or a response factory method. As a writer of middleware, it would make things slightly easier as I could just grab a virgin response from the delegate if I need it by calling $delegate->getFactory() or some such.

  You only need to inject a factory into once place rather than many, which is a bonus. But it's not a massive win, since your DI container makes injecting a factory into all the middleware that want it pretty trivial (I can't imagine the increased performance overhead is detectable).

  However, I'm not that DelegateInterface providing such method(s) obeys separation of concerns -- is the delegate's role only to give a response by running later middleware, or to provide a response more generally?

[schnittstabil]

Related: https://github.com/http-interop/http-middleware/pull/41#issuecomment-263984461

[shadowhand]

The expectation is that any middleware that needs to create HTTP messages will depend on PSR-17.

[mindplay-dk]

The expectation is that any middleware that needs to create HTTP messages will depend on PSR-17

That's definitely my expectation, down the line.

For the time being, simply depending on Diactoros has been working fine for me. Of course, you wouldn't like to end up with an application depending on two different implementations of PSR-7, hence PSR-17, but there is likely no harm in doing so right now, since, for any given request, ultimately one response is generated, so only one implementation of the response interface will be loaded per request anyway.

Definitely looking forward to PSR-17, but we're okay for the time being, since there's only really one or two implementations of PSR-7 to choose from, and not that many middleware components actually generate a response in the first place.