Slim: Decouple PSR-7 HTTP message implementation as a separate project

[plashenkov]

Hello!

Do you plan to move PSR-7 HTTP message implementation to a separate repository?
It would be nice to have your implementation as a standalone package.
Here: https://github.com/thephpleague/route/issues/32#issuecomment-76842562 you planned to do that if I understand correctly.

Thank you

[codeguy]

I'm afraid I spoke too soon. Slim's current implementation includes additional methods beyond the pure PSR7 spec, and if we separated it as it is now we would fragment the spec. Will try to introduce a pure Slim PSR7 implementation after the 3.x release.

[codeguy]

So there's a lot of varied opinions on this in IRC. Leaving open for now. Maybe this will happen. More info soon.

[plashenkov]

Some other implementations:
https://github.com/guzzle/psr7 (incomplete);
https://github.com/zendframework/zend-diactoros (don't know, looks like complete but there is not only PSR-7, also other stuff).

Your implementation of the standard will be extremely valuable for the community. ;)

[akrabat]

I'm generally in favour. Slim\Http has additional helper methods, but does conform to the interface, so it may be useful to others.

[codeguy]

Agreed. I'll take care of this soon.

[akrabat]

Due to dependencies on Slim\Interfaces\Http and Slim\Collection, I can't see how we can split out Slim\Http into its own component and still maintain BC.

This has to be a 4.0 thing.

[astax-t]

Won't it be better not to extend the Request class with proprietary methods as this potentially makes any middlewares implemented for Slim depend on this specific implementation of PSR7 standard and therefore less interoparable?

I understand the methods such as isPost do provide convenience and I wish these were part of the standard (even better - with a trait that implements them, similar to Psr\LogLoggerTrait).

May I suggest to have a static utility class with a few methods such as

public static function isPost(ServerRequestInterface $request) {
    return $request->getMethod() === 'POST';
}

I do realize that static classes are generally not considered good things, but this seems to be less evil than adding non-standard extensions to Request and therefore encouraging hidden dependency on Slim's implementation of ServerRequestInterface.

Sorry if it's wrong place to start this discussion - I'm happy to move it to a separate issue, if needed.

[designermonkey]

I would think that having a Request object of PSR-7 implementation, and a decorator object, ala new SlimRequest(new Request(...)); is more friendly than a static utility class; they only serve to pollute code and make it tightly coupled.

[astax-t]

Sure thing. Decorator does make sense as long as there is no externally-accessible code that relies on it (such as middleware that expects instance of SlimRequest instead of ServerRequestInterface). Such code would compromise interoperability, which was the key point of introducing PSR-7.

My worry is that having such convenient decorator will actually encourage writing code tightly coupled to Slim. Or even worse mistake that can be made by inexperienced developers - the code that formally requires standard ServerRequestInterface, but actually uses methods available only in SlimRequest.

[adambro]

IMHO sticking to PSR7-only methods is the responsibility of _middleware library author_, not the Slim framework creators. On the other hand it makes perfect sense for Slim to be easy to use for _application developers_ which make Slim as their framework of choice.

[designermonkey]

If a middleware developer wanted to couple to Slim's implementation, then let them. It's still PSR under the hood for the end level developer, but they would have the option to use Slim methods also.

[adambro]

One idea: have base Request and Response objects fully compatible with PSR7 and Slim-specific that just extend the base with convenience methods. It is as easy as using extends keyword and provides an easy option to test middleware with pure PSR7 implementation.

[designermonkey]

I still think a decorator pattern is better for this scenario.

[codeguy]

Closing in favor of #2045