Psr17 Laravel Package

Product Decisions This Supports

• Standardization & Compliance: Enables adherence to PSR-17 (HTTP Message Interface) for HTTP message factories (RequestFactory, StreamFactory, ResponseFactory, UriFactory), ensuring consistency across PHP-based HTTP tooling (e.g., HTTP clients, middleware, or frameworks).
• Framework Agnosticism: Allows teams to decouple from Laravel’s built-in HTTP factories, enabling portability to other PSR-compliant ecosystems (e.g., Symfony, Laminas, or custom HTTP stacks).
• Testing & Mocking: Simplifies unit testing by providing synthetic HTTP messages (e.g., mock requests/responses) without external dependencies, reducing test flakiness.
• Performance Optimization: Lightweight (~1.4kB) alternative to bloated HTTP libraries for high-throughput services (e.g., APIs, CLI tools) where PSR-17 compliance is required but no heavy framework is needed.
• Roadmap for HTTP Tooling: Justifies investment in PSR-17-compatible middleware, clients, or message processors by ensuring a stable, dependency-free foundation.
• Build vs. Buy: Avoids reinventing the PSR-17 wheel; ideal for teams prioritizing maintainability over custom implementations.
• PHP Version Alignment: Breaking change: Now requires PHP 8.1+, aligning with modern PHP ecosystems and enabling use of newer language features (e.g., typed properties, enums) for improved type safety and performance.

When to Consider This Package

• Avoid if:
  • Your stack already includes a PSR-17-compliant library (e.g., Symfony’s HttpFoundation, Guzzle’s PSR-7 wrapper) and switching adds friction.
  • You need real HTTP functionality (e.g., parsing/validating real requests/responses) beyond synthetic objects—use a library like nyholm/psr7 or symfony/http-foundation instead.
  • Your team lacks PHP/PSR familiarity or PHP 8.1+ support; the package’s minimalism and PHP version requirement may introduce compatibility challenges.
  • You’re building a full-fledged framework (e.g., Laravel alternative) and prefer built-in HTTP abstractions.
  • You rely on legacy PHP versions (<8.1) and cannot upgrade due to infrastructure constraints.
• Consider if:
  • You’re building a microservice, CLI tool, or library needing PSR-17 compliance without framework bloat.
  • Your tests or middleware rely on deterministic HTTP messages (e.g., for validation or transformation).
  • You’re evaluating HTTP message factories for a new project and want to avoid vendor lock-in.
  • Your team is already on PHP 8.1+ and seeks a lightweight, modern PSR-17 implementation for new development.

How to Pitch It (Stakeholders)

For Executives: "This package standardizes HTTP message handling across our PHP services using PSR-17, reducing technical debt and enabling reusable, framework-agnostic components. With PHP 8.1+ support, it aligns with modern PHP ecosystems, offering a lightweight (~1.4kB), MIT-licensed tool for APIs, middleware, or testing. It’s a future-proof foundation for HTTP tooling—consistent, portable, and easy to integrate or replace as needs evolve. Note: Requires PHP 8.1+, so we’ll need to confirm infrastructure compatibility."

For Engineering: *"loophp/psr17 (v1.0.6) now requires PHP 8.1+, giving us:

• Modern PHP features: Typed properties, enums, and better type safety.
• Synthetic HTTP objects: Perfect for testing/mocking without external deps.
• Framework-agnostic PSR-17: Build middleware/clients without Laravel/Symfony bloat. Tradeoffs:
• Breaking change: Drops PHP <8.1 support (verify your stack).
• No real HTTP parsing (use nyholm/psr7 for that). Ideal for: New projects on PHP 8.1+, microservices, or libraries needing lightweight PSR-17 compliance."*