- What is yiisoft/request-provider and what problem does it solve?
- It is a Yii3 package that supplies the current PSR-7 ServerRequestInterface to your application from a single, container-bound provider. Instead of constructing requests manually or threading them through every call, services and middleware depend on the small RequestProviderInterface. The provider builds the request from PHP superglobals using a PSR-17 factory, runs request body parsers, and caches the instance for the rest of the request lifecycle.
- How do I install yiisoft/request-provider with Composer?
- Run composer require yiisoft/request-provider in your Yii3 project. You also need a PSR-7 implementation and a matching PSR-17 factory, such as nyholm/psr7 with its factory, since the provider delegates request creation to PSR-17. Finally, bind RequestProviderInterface to the package's provider class in your dependency injection configuration so middleware and services can receive it.
- Does yiisoft/request-provider work with Laravel, or is it Yii3 only?
- It is a Yii3 package and is designed around Yii3's dependency injection container and middleware stack, so it is not a drop-in Laravel package. Laravel applications use Illuminate\Http\Request and Symfony HttpFoundation rather than PSR-7 server requests, so you should use Laravel's own request handling instead. Wiring this provider into Laravel would require custom PSR-7 bridging and is not a supported path.
- How do I get the current PSR-7 request inside a Yii3 service or middleware?
- Type-hint RequestProviderInterface in the constructor of your service or middleware and let the container inject it. Call the interface method that returns the ServerRequestInterface to obtain the current request without touching superglobals yourself. This keeps your classes testable and free of global state, and repeated calls return the same cached instance.
- Which PSR-7 and PSR-17 implementations can I use with this package?
- Any implementation compliant with PSR-7 and PSR-17 works, including nyholm/psr7, guzzlehttp/psr7, and laminas-diactoros with their corresponding factories. The package depends only on the PSR interfaces, so you choose the concrete library and bind its ServerRequestFactoryInterface in the container. This keeps your application portable if you later swap implementations.
- How are request body parsers used to populate the parsed body?
- After the server request is created, the provider runs the configured body parsers so that the parsed body is populated for content types such as JSON or form data. You register parsers through your Yii3 configuration, and you can add custom parsers for application-specific content types. Handlers can then read the parsed body directly instead of decoding the raw stream themselves.
- Is the ServerRequest cached, and will I always get the same instance?
- Yes, the provider caches the request it builds and returns that same instance on every subsequent call during the request lifecycle. This guarantees consistency across middleware and services, and avoids the cost of rebuilding the request from superglobals multiple times. The cache lives only for the current request, so each new request gets a freshly built instance.
- How do I test code that depends on RequestProviderInterface?
- Because your code depends on the interface rather than a concrete class, you can substitute a simple fake or mock in unit tests. Have the fake return a ServerRequest you create with any PSR-7 implementation, which removes the need to manipulate superglobals or bootstrap the framework. This makes request-dependent services straightforward to test in isolation.
- What PHP and Yii3 versions does it support, and how is it maintained?
- The package is part of the Yii3 ecosystem and follows its PHP version requirements along with the PSR-7 and PSR-17 interface packages. Check the composer.json constraints and the repository release notes before upgrading, since Yii3 packages are versioned in step with framework changes. Maintenance is handled by the Yii team, so pinning a tested version in production is advisable.
- What are the alternatives to using a request provider?
- You can build the PSR-7 request yourself with a PSR-17 factory during bootstrap or in a PSR-15 middleware and pass it along explicitly. Another option is to pass the ServerRequestInterface through middleware parameters or handler arguments rather than resolving it from the container. The provider approach is preferable when many unrelated services need the request and you want to avoid widening every method signature.