Wrap an HTTP client with typed, predictable methods and standardized error handling. The examples separate the essential operation from the conditions a production implementation must enforce.
What It Does
Wrap an HTTP client with typed, predictable methods and standardized error handling.
Prerequisites
Use a dedicated development environment with test accounts and records. Separate authorization, validation and error handling from response formatting; never copy demonstration-only secrets into production.
Example 1: Core Behavior
The first example isolates the core operation so its result is easy to understand.
<?php
$opts = ['timeout'=>5,'connect_timeout'=>2,'verify_tls'=>true];
if ($opts['timeout'] <= 0 || !$opts['verify_tls']) throw new RuntimeException('Unsafe client config');
echo json_encode($opts);
Example 2: Alternative or Failure Case
The second example demonstrates an alternative outcome, rule or failure condition.
<?php
$status=503; $body='{"message":"Unavailable"}';
if ($status>=500) { echo 'Retryable upstream error'; } else { echo json_decode($body,true,512,JSON_THROW_ON_ERROR)['message']; }
Practical Example: Applying the Rule
This practical workflow performs the relevant operation, with strict error checks. Configure the required transport or database driver before running it.
<?php
final class CatalogClient {
public function __construct(private string $baseUrl) {
if ($baseUrl !== 'https://api.example.test') throw new InvalidArgumentException('Unapproved API host');
}
public function find(int $id): array {
$ch = curl_init($this->baseUrl . '/items/' . $id);
curl_setopt_array($ch, [CURLOPT_RETURNTRANSFER => true, CURLOPT_CONNECTTIMEOUT => 3, CURLOPT_TIMEOUT => 8, CURLOPT_FOLLOWLOCATION => false]);
$body = curl_exec($ch);
if ($body === false) throw new RuntimeException('API transport failure: ' . curl_errno($ch));
$status = curl_getinfo($ch, CURLINFO_RESPONSE_CODE);
if ($status !== 200) throw new RuntimeException('Unexpected API status: ' . $status);
$data = json_decode($body, true, 512, JSON_THROW_ON_ERROR);
if (!is_array($data) || !isset($data['id'])) throw new UnexpectedValueException('Invalid API response');
return $data;
}
}
$client = new CatalogClient('https://api.example.test');
echo json_encode($client->find(12), JSON_THROW_ON_ERROR);
Important Behavior and Edge Cases
Set TLS verification, timeouts, auth and retry policy at the transport boundary.
Comparison with Related Functions or Patterns
| Approach | When it differs |
|---|---|
| Building a Simple API Client SDK | Wrap an HTTP client with typed, predictable methods and standardized error handling. |
| Related API or pattern | A thin SDK hides transport details without recreating a full HTTP framework. |
Common Beginner Mistakes
| Mistake | Correct approach |
|---|---|
| Ignoring timeouts, status codes or response JSON shape | Set TLS verification, timeouts, auth and retry policy at the transport boundary. |
| Substituting a related API without checking its semantics | A thin SDK hides transport details without recreating a full HTTP framework. |
Key Takeaways
- Wrap an HTTP client with typed, predictable methods and standardized error handling.
- Set TLS verification, timeouts, auth and retry policy at the transport boundary.
- A thin SDK hides transport details without recreating a full HTTP framework.
Select this API or pattern based on its documented behavior and the trust boundaries in your own application, and test all external integrations against their actual deployments.