Weave Code
Rest Process Bundle Laravel Package
cleverage/rest-process-bundle
CleverAge/RestProcessBundle adds REST integration to the CleverAge ProcessBundle for Symfony, letting you connect process workflows to HTTP APIs. Compatible with stable Symfony and LTS releases; pair it with the core ProcessBundle docs.
Dedicated bundle for Rest dependencies for the Process Bundle
Frequently asked questions about Rest Process Bundle
- Is cleverage/rest-process-bundle a Laravel package?
- No. cleverage/rest-process-bundle is a Symfony bundle that provides REST integration for CleverAge ProcessBundle v3, and it ships a bundle class, a DI extension, and a compiler pass. Laravel does not boot Symfony bundles, so FrameworkBundle-style wiring and the compiler pass will not execute inside a Laravel container. Laravel use is only possible if the underlying Client, ClientRegistry, and RequestTask classes are framework-agnostic enough to re-bind manually.
- Can I use cleverage/rest-process-bundle in a Laravel application?
- Only with a bespoke adapter. The integration surface you would replace is the bundle-and-DI layer: instantiate ClientRegistry in a Laravel service provider, register clients from config files instead of the compiler pass, and resolve RequestTask from the container. That glue is your code to own and may drift from upstream. For Symfony hosts, v3.2 is a drop-in minor upgrade from v3.0.
- How do I install cleverage/rest-process-bundle?
- Install it with Composer as cleverage/rest-process-bundle, then enable the bundle in your Symfony application and configure it per the docs/index.md usage guide. It is part of the CleverAge ProcessBundle project and targets ProcessBundle v3. The README states compatibility with Symfony stable and the latest LTS release. This installation path is for Symfony, not Laravel.
- What does RequestTask do in a CleverAge process workflow?
- RequestTask performs HTTP calls through a mockable client and exposes valid_response_code semantics for deciding which status codes are acceptable. It is the core runtime object for REST steps in ProcessBundle workflows. In v3.2, when a 3xx, 4xx, or 5xx code is listed in valid_response_code, the task now outputs the response body. The task still fails, so treat the body as diagnostic unless your downstream processors are updated.
- What changed in v3.2 that could affect existing pipelines?
- The highest-impact change is #35: response bodies now surface on failed status codes listed in valid_response_code, which can silently alter pipeline data if downstream processors assumed failure meant empty output. Logging changes in #37 and #36 now log the requested URL plus status code, headers, and response content, increasing log volume and PII or secret leakage risk. #38 adds an explicit UnexpectedValueException for non-array input, so existing catch blocks for TypeError or generic exceptions may no longer match. #39 deprecates Client::geUri() in favor of getUri().
- How should I handle valid_response_code failures after the v3.2 change?
- Post-#35, a listed 3xx, 4xx, or 5xx status still causes the task to fail, but the response body is now available as output. Treat that output as diagnostic-only on failure unless the documented contract says otherwise. Audit downstream processors that keyed off failed meaning empty output, and update tests to assert the new body-on-failure behavior. If you need strict empty output on failure, add an explicit processor step to discard or transform the body.
- Does log_response expose sensitive headers or tokens in logs?
- Yes, the v3.2 logging change means log_response now logs the requested URL plus status code, headers, and response content. That can include authorization headers, tokens, and PII in response bodies. The context does not document a redaction allow-list for headers or bodies. If that is a concern, disable log_response and implement your own logging with redaction, and expect larger log volume after upgrading.
- Which Symfony versions does cleverage/rest-process-bundle support?
- The README says it is compatible with Symfony stable and the latest Long-Term Support release. For v3.2, the narrower compatibility question is which Symfony component versions the standalone classes require, such as HttpClient, OptionsResolver, and DI contracts. Check those component constraints against your host application, especially if you are evaluating PHP 8.5 or Symfony 8. This matters for Laravel too, because Laravel pins Symfony components.
- How do I test REST process tasks with cleverage/rest-process-bundle?
- RequestTask performs HTTP calls through a mockable client, so inject a mock Client in tests to avoid real network requests. In Symfony, use the bundle's DI wiring; in a Laravel adapter, bind a fake Client or ClientRegistry in the service container. Assert both success and failure paths, including the v3.2 behavior where response bodies surface on failed valid_response_code statuses. Also test non-array input to confirm the new UnexpectedValueException path.
- What are the alternatives to cleverage/rest-process-bundle for Laravel?
- For Laravel applications, use Laravel's HTTP client or Guzzle directly, or choose a workflow package with native Laravel support, rather than trying to boot a Symfony bundle. If you specifically need CleverAge ProcessBundle semantics, build a custom adapter around the standalone Client, ClientRegistry, and RequestTask classes. Weigh the maintenance cost of owning that adapter and the v3.2 behavior changes before committing. For Symfony services already using ProcessBundle, the bundle remains the natural fit.
Weaver
How can I help you explore Laravel packages today?