Rest Process Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — buy only the runtime, not the bundle. The value here is a small, tested set of classes: RequestTask (declarative HTTP calls with valid_response_code semantics), Client (URL/parameter handling), ClientRegistry (clients registered by code), and MissingClientException. That is a real, maintained abstraction worth taking rather than re-implementing. What we cannot take is the delivery mechanism: the bundle class, DI extension, compiler pass and services.yaml wiring are Symfony-specific and will not boot inside a Laravel container. The PM decision is "adopt the runtime classes, budget a thin Laravel service provider," not "install the package."
• Roadmap: this is a reliability line item, not a platform line item. Recent releases are correctness work in failure paths — transport errors now actually get logged, log_response records the requested URL plus status/headers/content instead of a response-object dump, valid_response_code entries for 3xx/4xx/5xx return the body while still failing the task, non-array input throws an explicit UnexpectedValueException, duplicate client codes name both colliding service IDs. Nothing here forces a PHP or Symfony upgrade, so it must not be used as justification to pull a framework upgrade into the roadmap.
• Feature decisions it enables. Response-validation-driven workflows against third-party REST APIs — the pattern where a non-2xx code is expected and the body still needs inspecting (partner APIs that return 200-with-error-payload or 409-with-remediation-detail). Declarative client configuration per environment. Outbound-call orchestration as configuration rather than hand-wired service classes.
• Observability/diagnosability as a product investment. The strongest argument for this dependency is not throughput, it is mean-time-to-diagnose. Failures that were previously silent or mislogged now produce actionable log lines. That is a support-cost reduction we can put a number against.
• Deprecation chore, scheduled not urgent. Client::geUri() → Client::getUri() is a greppable rename with identical behaviour. Track it as low-priority cleanup before our next major, not a project.
• Use cases to design against. Internal pipeline tooling, partner/API-integration workflows, ops dashboards that trigger and inspect REST-backed processes, and any flow where "was the call made, what did it return, why did it fail" must be answerable from logs alone.

When to Consider This Package

Adopt if all of the following hold:

• You have several outbound REST integrations with per-call response expectations, not one or two calls.
• You want clients declared in configuration (code, base URL, headers, valid response codes) so integrations are data, not code.
• You are comfortable owning the framework glue — in a Laravel house this means writing and maintaining a service provider that binds Client, ClientRegistry and RequestTask, and accepting that the bundle's compiler pass is replaced by our own registration.
• You need non-2xx codes to be validated and inspectable while still failing the task, with reliable logging of what went over the wire.
• You value a maintained, tested dependency over an internal helper library — but with eyes open that "tested" here means a small suite with a mocked HTTP client, and the community footprint is effectively nil (0 stars, 0 dependents).

Look elsewhere, or scope down hard, if any of the following hold:

• You are a Laravel-first team. This is a Symfony bundle. Laravel does not boot Symfony bundles; the DI extension and compiler pass will not execute in a Laravel container. Unless the underlying classes are framework-agnostic enough to re-bind manually — and we should verify that with a spike before committing — the honest answer is "use Laravel's HTTP client plus a small internal registry."
• You have a single, simple outbound call — the registry/compiler-pass machinery is pure overhead at that scale.
• You need typed DTO mapping, OpenAPI/JSON-Schema contract validation, retries/backoff policy, circuit breaking, or non-HTTP transports. This package validates response codes, not payload contracts.
• Your support posture requires a vendor, SLA, or an active maintainer community. Zero stars and zero dependents is not disqualifying for an MIT library, but it means we are the maintainers-in-practice. If that is unacceptable, stop here.
• Your risk function requires no deprecations between minors — this project has historically deprecated typos and tightened types in minor releases.

How to Pitch It (Stakeholders)

Executives (one paragraph): "We evaluated this library for connecting our workflows to third-party REST APIs. The engineering value is real and the maintenance line is active — recent releases are all about making failures diagnosable: errors that were previously silent now log the real URL, status, headers and body, and misconfigurations now name the offending services. But there is a fit problem: it is built for Symfony, and we run Laravel. Adopting it means we write and own a small integration layer ourselves. My recommendation is a timeboxed two-day spike to confirm the core classes are framework-agnostic; if they are, we take the library and own roughly a day of glue, which is still cheaper than building equivalent behaviour. If they are not, we fall back to the framework's HTTP client plus a lightweight internal registry — a similar outcome for similar cost, without the dependency. Either way, this is a small, low-risk line item, not a platform decision."

Engineering (summary): "cleverage/rest-process-bundle gives us RequestTask (HTTP calls with per-call valid_response_code rules), Client, and a ClientRegistry keyed by client code, plus tests around the error paths. It is a Symfony bundle — the bundle class, DI extension and compiler pass will not run under Laravel. So the proposal is to consume the framework-agnostic runtime classes and re-bind them in a Laravel service provider; everything else is ours.

Worth knowing before the spike: valid_response_code entries for 3xx/4xx/5xx now return the response body while still failing the task (previously the body was lost); log_response logs the requested URL and real status/headers/content, not the configured URL and a response object; transport errors are logged rather than swallowed; non-array input to RequestTask throws an explicit UnexpectedValueException; scalar URL params are cast to string. One deprecation: Client::geUri() → Client::getUri() — mechanical rename, identical behaviour.

Risks, stated plainly: near-zero community (0 stars, 0 dependents) means we are the de-facto maintainers of any fork or glue; and the bundle layer is dead weight for us. Exit criteria for the spike: the four runtime classes instantiate without Symfony DI, and one real endpoint works end-to-end through our provider. If either fails, take the fallback."