Conversation
Allow passing a pre-configured HTTP client (e.g. Guzzle) to the Client. This enables reuse of middleware stacks (e.g. Laravel retry/cache) instead of forcing the internal cURL transport.
feat: support custom HTTP client injection
|
@francescobianco I’ve reopened the PR for this ticket. The previous one wasn't merged due to a branching error on my end. This one is ready for review and merge. |
Added Tests namespace
load Tests Namespace only in autoload-dev
| "autoload": { | ||
| "psr-4": { | ||
| "OpenApi\\": "src", | ||
| "OpenApi\\": "src" |
There was a problem hiding this comment.
Use name convention: https://github.com/openapi/openapi-naming?tab=readme-ov-file#6-php
There was a problem hiding this comment.
@francescobianco Okay, I will implement it and update everything to the correct naming convention. Just a heads up: the changes for Ticket #12 are already in my local branch, so they will be included in the next push. Sorry about that, but I think it’s all set now!
There was a problem hiding this comment.
@francescobianco, I've updated the PR description and everything else as best as I can to show that I'm working on both tickets.
3 participants
Ticket: #6
Allow passing a pre-configured HTTP client (e.g. Guzzle) to the Client. This enables reuse of middleware stacks (e.g. Laravel retry/cache) instead of forcing the internal cURL transport.
📋 Description
This PR adds support for injecting a custom HTTP client into the SDK Client.
Previously, all requests were executed via an internal cURL implementation. This made it impossible to reuse existing HTTP client configurations and middleware stacks (e.g. Laravel retry() or cache()), as they were bypassed entirely.
With this change, users can now provide a pre-configured HTTP client (such as Guzzle or any PSR-18 compatible client). This allows requests to be executed through the application's existing HTTP layer, enabling middleware reuse, connection pooling, and consistent configuration.
The default behavior remains unchanged: if no custom client is provided, the SDK continues to use its internal cURL transport.
This improves flexibility while keeping the SDK lightweight and framework-agnostic.
New Features & Improvements #12:
DotEnv Support: The system now includes DotEnv functionality for environment variable management.
Framework Compatibility: DotEnv loading is optional. The previous configuration method is still fully supported.
Smart Loading: To prevent conflicts, a guard has been added to OpenapiBootstrap.php. If the environment already provides DotEnv (e.g., in Laravel), the SDK will not perform an additional load.
Naming Convention: All namespaces and classes have been updated to the new Openapi naming convention.
Testing: Comprehensive test cases for the new environment logic have been added.
The default behavior remains unchanged: if no custom client is provided, the SDK continues to use its internal cURL transport.
This improves flexibility while keeping the SDK lightweight and framework-agnostic.
✨ Type of Change
🔍 Main Changes
or a PSR-18 compatible HTTP client (e.g. Guzzle)
🧪 Testing
./vendor/bin/phpunit)📝 Additional Notes
Added support for psr/http-client to allow integration with PSR-18 compatible HTTP clients (e.g. Guzzle)
No framework-specific dependencies were introduced
Guzzle support is implicit via PSR-18 and remains optional
Default cURL transport remains unchanged and is used when no custom client is provided
🔗 Related Issue
Closes #6
Close #12
📸 Screenshots (if applicable)
✅ Checklist