Changing the Underlying Client
Learn how to switch between different HTTP client implementations using the Instructor HTTP client API.
One of the core features of the Instructor HTTP client API is its ability to seamlessly switch between different HTTP client implementations. This flexibility allows you to use the same code across different environments or to choose the most appropriate client for specific use cases.
Available Client Drivers
The library includes several built-in drivers that adapt various HTTP client libraries to the unified interface used by Instructor:
GuzzleDriver
The GuzzleDriver
provides integration with the popular Guzzle HTTP client.
Key Features:
- Robust feature set
- Excellent performance
- Extensive middleware ecosystem
- Support for HTTP/2 (via cURL)
- Stream and promise-based API
Best For:
- General-purpose HTTP requests
- Applications that need advanced features
- Projects without framework constraints
Requirements:
- Requires the
guzzlehttp/guzzle
package (composer require guzzlehttp/guzzle
)
SymfonyDriver
The SymfonyDriver
integrates with the Symfony HTTP Client.
Key Features:
- Native HTTP/2 support
- Automatic content-type detection
- Built-in profiling and logging
- No dependency on cURL
- Support for various transports (native PHP, cURL, amphp)
Best For:
- Symfony applications
- Projects requiring HTTP/2 support
- Low-dependency environments
Requirements:
- Requires the
symfony/http-client
package (composer require symfony/http-client
)
LaravelDriver
The LaravelDriver
integrates with the Laravel HTTP Client.
Key Features:
- Elegant, fluent syntax
- Integration with Laravel ecosystem
- Built-in macros and testing utilities
- Automatic JSON handling
- Rate limiting and retry capabilities
Best For:
- Laravel applications
- Projects already using the Laravel framework
Requirements:
- Included with the Laravel framework
MockHttpDriver
The MockHttpDriver
is a test double that doesn’t make actual HTTP requests but returns predefined responses.
Key Features:
- No actual network requests
- Predefined responses for testing
- Response matching based on URL, method, and body
- Support for custom response generation
Best For:
- Unit testing
- Offline development
- CI/CD environments
Switching Between Clients
You can switch between the available client implementations in several ways:
When Creating the Client
The simplest approach is to specify the client when creating the HttpClient
instance:
The client name must correspond to a configuration entry in your config/http.php
file.
Using the Default Client
If you don’t specify a client, the default one from your configuration will be used:
The default client is specified in the config/http.php
file:
Switching at Runtime
You can switch to a different client at runtime using the withClient
method:
This allows you to adapt to different requirements within the same application.
Using the Static Make Method
The HttpClient
class provides a static make
method as an alternative to the constructor:
Client-Specific Configuration
Each client type can have its own configuration in the config/http.php
file:
Multiple Configurations for the Same Client Type
You can define multiple configurations for the same client type, each with different settings:
Then you can select the appropriate configuration based on your needs:
Common Configuration Parameters
All client types support these common configuration parameters:
Parameter | Type | Description |
---|---|---|
httpClientType | string | The type of HTTP client (Guzzle, Symfony, Laravel) |
connectTimeout | int | Maximum time to wait for connection establishment (seconds) |
requestTimeout | int | Maximum time to wait for the entire request (seconds) |
idleTimeout | int | Maximum time to wait between data packets (seconds, -1 for no timeout) |
maxConcurrent | int | Maximum number of concurrent requests in a pool |
poolTimeout | int | Maximum time to wait for all pooled requests (seconds) |
failOnError | bool | Whether to throw exceptions for HTTP error responses |
Client-Specific Parameters
Some parameters might only be relevant to specific client implementations. For example, Guzzle supports additional options like verify
(for SSL verification) or proxy
settings that can be passed through the underlying client.
Example: Choosing the Right Client for Different Scenarios
Here’s an example of selecting different client configurations based on the task:
Considerations for Switching Clients
When switching between different HTTP client implementations, keep these considerations in mind:
-
Configuration Consistency: Ensure that all client configurations have the appropriate settings for your application’s needs.
-
Feature Availability: Some advanced features might be available only in specific clients. For example, HTTP/2 support might be better in one client than another.
-
Error Handling: Different clients might have slightly different error behavior. Instructor HTTP client API normalizes much of this, but edge cases can still occur.
-
Middleware Compatibility: If you’re using middleware, ensure it’s compatible with all client types you plan to use.
-
Performance Characteristics: Different clients may have different performance profiles for specific scenarios. Test with your actual workload if performance is critical.
In the next chapter, we’ll explore how to customize client configurations in more detail, including runtime configuration and advanced options.