Http Client Bundle Laravel Package

Product Decisions This Supports

• Unified API Client Strategy: Standardize HTTP client usage across Symfony-based microservices or monoliths, reducing technical debt from ad-hoc solutions (e.g., Guzzle, cURL).
• PSR-18/PSR-17 Compliance: Align with modern PHP standards to future-proof integrations with other PSR-compliant libraries (e.g., API gateways, middleware).
• Configuration-Driven Flexibility: Enable non-engineering teams (e.g., DevOps, backend) to tweak HTTP behavior (e.g., JSON encoding, URL strategies) via YAML without code changes.
• Decoupling Business Logic: Isolate HTTP concerns (e.g., retries, timeouts) from business logic by leveraging Symfony’s dependency injection and service tags.
• Roadmap for API-Centric Products:
  • Phase 1: Replace legacy HTTP clients in existing services.
  • Phase 2: Extend with custom middleware (e.g., auth, rate limiting) via PSR-18.
  • Phase 3: Integrate with Symfony Messenger for async API calls.

When to Consider This Package

• Adopt When:

  • Your stack is Symfony 5+ and you need a PSR-18-compliant HTTP client (avoiding vendor lock-in).
  • You prioritize configuration over code for HTTP behavior (e.g., JSON handling, URL encoding).
  • You’re building modular services where HTTP clients need to be swappable (e.g., for testing or feature flags).
  • Your team already uses Symfony’s DI and wants to avoid reinventing client registration/management.
  • You need lightweight HTTP operations (no heavy frameworks like Guzzle’s full suite).

• Look Elsewhere If:

  • You’re not using Symfony (this bundle is Symfony-specific).
  • You need advanced features like HTTP/2, WebSockets, or GraphQL (consider Guzzle or Symfony’s built-in HttpClient).
  • Your team lacks Symfony expertise (steepness of learning curve for DI/configuration).
  • You require enterprise-grade support (this package has 0 stars; opt for maintained alternatives like symfony/http-client).
  • You’re building a non-PHP backend (e.g., Go, Node.js).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us standardize how our Symfony services talk to APIs—reducing bugs from inconsistent HTTP clients and making it easier to swap providers later. For example, if we need to switch from Guzzle to a custom client, we only update one config file. It also aligns with modern PHP standards, so our engineers can focus on business logic instead of reinventing HTTP wheels. Low risk (MIT license, minimal footprint), high reward for maintainability."

For Engineering:

*"This bundle gives us a PSR-18-compliant HTTP client for Symfony with zero-boilerplate setup. Key benefits:

• Unified config: Control JSON encoding (e.g., JSON_OBJECT_AS_ARRAY) and URL strategies via YAML.
• Service tags: Register clients as Symfony services with dormilich_http_client.tag, enabling easy dependency injection.
• PSR-17/PSR-18: Future-proof for integrations with other PSR-compliant tools.
• Lightweight: No bloat—just what we need for API calls.

Tradeoff: It’s Symfony-only, but if we’re already using Symfony, this cuts down on Guzzle/GuzzleHttp dependencies and centralizes HTTP logic. Perfect for microservices or monoliths where consistency matters."*

For Backend/DevOps:

*"Need to tweak how your Symfony app handles API requests? This bundle lets you:

• Change JSON encoding (e.g., for legacy systems) via config/packages/dormilich_http_client.yaml.
• Switch URL encoding strategies (e.g., php vs nvp) without code changes.
• Tag HTTP clients in services.yaml for reuse across services.

Example: If your team needs to force JSON_OBJECT_AS_ARRAY for all API responses, just add:

dormilich_http_client:
  decoder:
    json: !php/const JSON_OBJECT_AS_ARRAY

No PRs, no deployments—just config."*