Restclientbundle Laravel Package

Getting Started

This is a Symfony bundle wrapping PHP's native curl_* functions. There is no README-level documentation beyond the description, so treat the source as the spec.

Minimal setup:

1. composer require prolix/restclientbundle
2. Register the bundle. On modern Symfony with Flex this is usually automatic; otherwise add it to config/bundles.php:

   return [
       // ...
       Prolix\RestClientBundle\RestClientBundle::class => ['all' => true],
   ];
   

3. Open vendor/prolixtechnikos/ci-rest-client-bundle/DependencyInjection/ (or Resources/config/services.*) to discover the actual service ID, the config root alias, and the client class name. Do this before writing config YAML — the alias rarely matches the composer name.
4. Add the config block under config/packages/ using the alias you found (expect something like rest_client: with base_url, timeout, headers keys).
5. Autowire the client into a controller or a small service and make one GET:

public function __construct(private \Prolix\RestClientBundle\RestClient $client) {}

public function ping(): array
{
    $response = $this->client->get('/health');
    return json_decode($response->getBody(), true);
}

First real use case: a single internal, JSON-over-HTTPS endpoint where you control both sides. Do not start with a third-party API — you want to isolate "is my bundle wiring correct" from "is their API behaving."

Implementation Patterns

Wrap it, don't inject it everywhere. The client is a thin transport. Create one small service per external system:

final class BillingApi
{
    public function __construct(private RestClient $client) {}

    public function charge(string $customerId, int $cents): array
    {
        $res = $this->client->post('/charges', [
            'customer' => $customerId,
            'amount'   => $cents,
        ]);

        if ($res->getStatusCode() >= 400) {
            throw new ApiException($res->getBody(), $res->getStatusCode());
        }

        return json_decode($res->getBody(), true, flags: JSON_THROW_ON_ERROR);
    }
}

This is the pattern that pays off day to day: verb methods stay generic, domain methods become typed and testable.

Configure base URL, auth, and timeout globally; override per call. Set base_url and default headers in the bundle config, then pass per-request headers for things like Idempotency-Key. Check the source for the merge order — most thin wrappers append per-request headers and shadow duplicates, but verify.

Handle bodies as strings, decode at the boundary. The wrapper almost certainly returns the raw cURL body. Centralize json_decode(..., JSON_THROW_ON_ERROR) in your wrapper so malformed responses surface as a clear exception rather than a null that propagates.

Test by stubbing at your wrapper boundary, not the HTTP layer. With zero tests and no PSR-18/PSR-7 interface, mocking the bundle's client is brittle. Type-hint your own BillingApi against an interface and fake that; run the real bundle client only in integration tests.

Don't mix it with Symfony HttpClient in the same service. Pick one per integration. Two different exception models and two different timeout semantics in one class is a debugging trap.

Use the compiler pass / service override for cross-cutting concerns. If you need correlation-ID headers or request logging, decorate the bundle's service definition in a Kernel::build() compiler pass rather than threading it through every call site.

Gotchas and Tips

• GPL-3.0. This is the biggest practical concern. GPL is copyleft; linking it into a proprietary Symfony app is a legal question, not a technical one. Get sign-off before shipping, or keep it out of the main application.
• Zero stars, zero dependents, single release. Assume no upstream fixes. Fork it into your own namespace on day one so you can patch cURL behavior without breaking your lockfile discipline.
• cURL semantics leak through. Expect CURLOPT_* behavior to surface in odd ways: timeout vs connect_timeout may not both be configurable, SSL verification may default off (grep for CURLOPT_SSL_VERIFYPEER), and redirects may be disabled by default. Audit these three before production.
• No async, no retries, no connection reuse. A bare curl_exec per call means serial request latency. If you need concurrency, you are writing curl_multi yourself — at which point you should switch to Symfony HttpClient, which gives you HttpClientInterface plus a mockable MockHttpClient.
• Error model is likely return-value based. curl_exec returns false on transport failure. Determine whether the bundle throws, returns a response with status 0, or returns false, and normalize it in your wrapper. Silent false is the most common bug here.
• Service ID and config alias are not derivable from the package name. prolix/restclientbundle maps to RestClientBundle but the DI alias could be prolix_rest_client, rest_client, or ci_rest_client. bin/console debug:container | grep -i rest finds it in seconds.
• Bundle registration may assume pre-Flex Symfony. If services.xml uses old argument syntax or the extension class lacks Configuration return types, you may get deprecation noise or hard failures on Symfony 6/7. Test bundle boot on your exact Symfony version as step one.
• Extension points are limited. Realistically you get three: constructor arguments via config, service decoration, and subclassing the client. There is no middleware stack, no event dispatch, no RequestInterface. Plan your design so all of that lives in your wrapper.
• Debugging cURL failures. Enable CURLOPT_VERBOSE to a stream via a config option if exposed; otherwise temporarily patch your fork. Capture curl_error($ch) and curl_errno($ch) — the bundle may swallow them, and "empty 500 response" with no diagnostic is the worst failure mode this class of package produces.
• Verify TLS and timeouts in a staging call before trusting it. Fire one request at a known-bad host and confirm you get a catchable exception rather than a hang.