Weave Code
Psr18 Transport Laravel Package
php-soap/psr18-transport
PSR-18 transport for php-soap, letting you drive SOAP clients through any PSR-18 HTTP client. Swap in your preferred HTTP library, keep full control of requests and middleware, and integrate SOAP cleanly with modern PHP HTTP stacks.
PSR-18 HTTP Client transport for SOAP
Frequently asked questions about Psr18 Transport
- How do I install php-soap/psr18-transport in a Laravel or PHP project?
- Install it with Composer via composer require php-soap/psr18-transport. You also need a PSR-18 HTTP client and PSR-7/PSR-17 request and stream factories, such as Guzzle with guzzlehttp/psr7, Symfony HttpClient, or Nyholm. The package is framework-agnostic, so there is no Laravel service provider to publish; you wire the transport into your php-soap client construction manually.
- Which PSR-18 HTTP clients can I use with php-soap/psr18-transport?
- Any client implementing Psr\Http\Client\ClientInterface will work, which includes Guzzle, Symfony HttpClient via its PSR-18 adapter, Nyholm PSR-7, and most modern PHP HTTP libraries. Because the transport only depends on the PSR-18 interface, swapping clients does not require code changes to the transport itself. Confirm the exact client and middleware versions you plan to use are validated in your own test suite.
- Does php-soap/psr18-transport support both SOAP 1.1 and SOAP 1.2?
- The transport carries HTTP messages and leaves SOAP envelope and version semantics to php-soap, so SOAP 1.1 and 1.2 behavior depends on your php-soap client configuration. You should explicitly test both versions, including Content-Type headers and SOAPAction handling, against your target services. Treat protocol-level validation as part of your integration checklist rather than assuming parity with ext-soap.
- Can I apply Guzzle or Symfony middleware for logging, retries, and auth to SOAP calls?
- Yes. Because requests flow through a standard PSR-18 client, existing middleware for authentication, logging, tracing, and retries applies to SOAP traffic just like REST traffic. Be careful with retry middleware: SOAP operations are often non-idempotent, so retrying on timeouts or 5xx responses can duplicate business actions. Define idempotency rules before enabling automatic retries.
- Does php-soap/psr18-transport replace ext-soap entirely?
- No. It replaces php-soap's default HTTP transport with a PSR-18 client, decoupling SOAP message delivery from ext-soap's built-in HTTP handling. You still use php-soap as the SOAP engine for WSDL parsing and envelope building. If your code calls ext-soap's SoapClient directly, this package alone will not change that.
- Is php-soap/psr18-transport production-ready given its low star count?
- It is MIT-licensed and recently maintained, but with roughly 18 stars and an unknown public repository, it should be treated as a low-adoption dependency that your team owns. Pin versions, gate automated dependency updates behind SOAP contract tests, monitor releases and security advisories, and keep a fork or rollback path to the previous transport. Start with a non-critical integration and expand only after side-by-side validation.
- How do I unit test SOAP requests using a mocked PSR-18 client?
- Inject a mock PSR-18 client that implements ClientInterface, capture the outgoing PSR-7 request, and assert the SOAP envelope, headers, and endpoint are correct. This avoids network calls and makes SOAP integrations testable in CI. Pair these tests with a small set of contract tests against a real or stubbed SOAP server to catch protocol-level regressions.
- Does the package handle SOAP attachments, MTOM, and WS-Security?
- Those are SOAP-level concerns rather than HTTP transport concerns, so support depends on php-soap and any middleware you add. Attachments, MTOM, and WS-Security headers must be proven explicitly in your environment before relying on them. If they are critical, validate end-to-end payloads and plan middleware or alternative handling where gaps appear.
- What happens to SOAP faults and HTTP error responses with a PSR-18 transport?
- The PSR-18 client returns an HTTP response, and php-soap is responsible for parsing SOAP faults from the body. Transport-level failures, such as connection errors or non-2xx responses, will typically surface as PSR-18 exceptions unless your middleware or php-soap maps them. Verify in tests that faults are preserved, that error mapping is consistent, and that middleware does not swallow SOAP fault bodies.
- What are the alternatives to php-soap/psr18-transport?
- Alternatives include php-soap's default transport, calling ext-soap's SoapClient directly, or writing a custom transport that implements php-soap's transport interface on top of your preferred HTTP client. Some teams use higher-level SOAP client wrappers that bundle transport and middleware. Choose based on whether you need shared PSR-18 egress, middleware reuse, and testability, or simply the lowest-dependency path.
Weaver
How can I help you explore Laravel packages today?