Psr18 Transport Laravel Package

Technical Evaluation

• Architecture fit: Strong fit where the organization already uses the php-soap ecosystem and wants SOAP traffic to flow through the same PSR-18 HTTP client stack used by REST/other integrations. The package decouples SOAP transport from ext-soap, enabling centralized auth, logging, retries, and test mocking. It is less attractive as a greenfield SOAP abstraction or where teams still call ext-soap directly.
• Integration feasibility: Likely low-to-medium effort. Composer-based installation, a PSR-18 client, and PSR-7/PSR-17 factories are required. If the team already has Guzzle or Symfony HttpClient with middleware, the main work is wiring the transport into php-soap client construction and validating SOAP-specific behavior. If not, the team must first standardize an HTTP client and middleware stack.
• Technical risk: Adoption risk is material: only 18 stars, repository unknown, and a small ecosystem footprint. The package is MIT-licensed and recent, but low community validation means the team should expect to own hardening, compatibility testing, and possibly a fork. SOAP edge cases—attachments/MTOM, WS-Security, SOAP 1.1/1.2 differences, WSDL retrieval, cookies, redirects, proxies, and non-idempotent retries—must be explicitly tested. PSR-18 is synchronous, so it does not by itself provide async or streaming SOAP support.
• Key questions: Which php-soap engine/client versions are supported? Does the package preserve SOAP faults and HTTP error semantics? Are attachments, MTOM, WS-Security, and custom SOAP headers supported or delegated to middleware? Which PSR-18 client and middleware versions are validated? What is the maintenance plan given the low star count and unknown repository? Does retry middleware risk duplicate business operations? What observability and secret-rotation patterns are required?

Integration Approach

• Stack fit: Best fit for PHP services already using Composer, PSR-18, and PSR-7/17—especially Symfony HttpClient or Guzzle shops. Reuse existing auth, logging, tracing, and retry middleware rather than introducing a second HTTP egress path. Confirm PHP runtime, php-soap version, and PSR dependency constraints before committing.
• Migration path: Start with a non-critical SOAP integration in a development environment. Run the new PSR-18 transport side-by-side with the existing ext-soap transport, compare request/response payloads, SOAP faults, headers, timing, and attachment behavior. Promote to staging with production-like WSDL and auth, then canary one low-risk production consumer before broader rollout.
• Compatibility: Validate SOAP 1.1/1.2, WSDL/XSD caching, TLS/proxy settings, timeouts, redirects, cookies, compression, and error mapping. Confirm how the package handles SOAP faults versus transport exceptions. If WS-Security, MTOM, or large attachments are required, prove support explicitly or plan middleware/alternative handling. Pin package and PSR dependency versions and test against the exact client/middleware stack.
• Sequencing: (1) inventory SOAP integrations and classify risk; (2) confirm dependency and version compatibility; (3) build a reference client with the chosen PSR-18 implementation; (4) add auth, logging, tracing, and retry middleware with idempotency rules; (5) create contract tests and mocked-client tests; (6) pilot in dev/staging; (7) canary production; (8) document runbooks and rollback to the prior transport.

Operational Impact

• Maintenance: Treat the package as a small, low-adoption dependency requiring internal ownership. Pin versions, monitor releases and security advisories, and maintain a fork/rollback option under MIT. Automate dependency updates but gate them behind SOAP contract tests. Recent release activity is positive, but low stars and unknown repository mean community support should not be assumed.
• Support: Expect community-only support unless a commercial arrangement exists. Define an internal escalation path, a designated maintainer, and a runbook covering transport configuration, middleware order, certificate rotation, and rollback. Budget time for debugging interactions between SOAP, PSR-18 clients, and middleware rather than package-internal defects alone.
• Scaling: Throughput and connection pooling depend on the underlying PSR-18 client, not this package. SOAP payload size and synchronous request/response behavior can create memory and latency pressure. Use client-level pooling, timeouts, circuit breakers, and concurrency limits. Do not assume async support; long-running SOAP operations need queueing or worker isolation.
• Failure modes: Watch for HTTP client exceptions masking SOAP faults, retry middleware duplicating non-idempotent operations, auth/token expiry, TLS/proxy misconfiguration, WSDL fetch failures, attachment/MTOM corruption, and middleware ordering bugs. Add idempotency keys or disable retries for unsafe operations, emit structured logs/traces per SOAP call, and define dead-letter/alerting behavior.
• Ramp-up: PHP developers familiar with PSR standards should ramp quickly; SOAP-specific knowledge and middleware debugging take longer. Estimate a few days for a pilot and one to two sprints for production hardening, observability, and rollback validation. Provide training on the php-soap client wiring, middleware order, retry safety, and SOAP fault handling.