Soap Api Laravel Package

Getting Started

webit/soap-api is a Laravel package (circa 2017, dbojdo) that wraps PHP’s ext-soap and provides helpers for exposing and consuming SOAP services inside a Laravel app. It is old, unversioned, and has no dependents — treat it as a reference implementation you will likely fork rather than a drop-in dependency.

Minimal setup:

1. Require it. composer require webit/soap-api — expect conflicts on modern Laravel (it targets Laravel 5.x / PHP 7.0–7.1). If it won’t install, pull the repo in as a path repository or vendor a copy into packages/.
2. Ensure ext-soap is loaded. php -m | grep soap. Most build failures on first contact are actually missing ext-soap, not a package bug.
3. Register the service provider. Add the package provider (and its Facade, if you use one) to config/app.php. In Laravel 5.5+ auto-discovery won’t fire because the package predates it.
4. Publish config with php artisan vendor:publish and scan the published file for the WSDL path/cache and namespace options — that is the first thing to read.
5. Explore src/ before writing code. With no README docs to speak of, the source is the documentation. Look for: a base controller, a WSDL builder, any annotation or config-driven service definitions, and a client wrapper.
6. First use case: expose an existing (external) WSDL through a Laravel controller so your frontend or partner can call one stable endpoint, proxying to the upstream service via the package’s client.

If composer require produces a dependency resolution conflict, stop and read the composer.json in the repo — the answer is almost always the Laravel/illuminate/* version constraint.

Implementation Patterns

Server-side (exposing a SOAP API):

• Extend the package’s base controller / service class and map each public method to a SOAP operation. PHP’s SoapServer uses a specific URI from the WSDL, so the method names must match the WSDL exactly.
• Generate or provide the WSDL. If the package ships a builder, define operations, types, and bindings in one place (config or annotations) so the WSDL and the PHP method signatures can’t drift.
• Register the endpoint as a normal route. SOAP is POST + XML, so keep CSRF excluded for that URI (VerifyCsrfToken::$except, or route it through the api group without session middleware).
• Return plain arrays or stdClass from operation methods. Anything that serializes to the XSD type is fine; Eloquent models are not — map them first.

Client-side (consuming a remote SOAP service):

• Wrap the package client in a small service class per upstream API, and inject that into your application code. This gives you a seam for fakes and one obvious file to update when the upstream WSDL changes.
• Use SoapClient::__setLocation() and the WSDL cache options (cache_wsdl, stream_context) via the package config rather than editing the vendor source — that is what the config file is for.
• Turn on trace: true in non-production so __getLastRequest() / __getLastResponse() are available for debugging.

Integration tips:

• Proxying pattern: define a Laravel controller + package service that accepts SOAP, calls the upstream, and returns the mapped response. Keeps your public API stable while the upstream changes.
• Testing: don’t hit the network. Wrap the client and inject a fake, or use a recorded XML fixture. The SoapClient final classes make direct mocking painful — the wrapper is the point.
• Versioning the WSDL: keep the WSDL file in resources/soap/ and reference it from config, so a schema change is a reviewable diff.
• Queue long upstream calls. SOAP calls are synchronous and often slow; a queued job calling the client is the standard Laravel fix.

Gotchas and Tips

• It is effectively abandoned. Last release 2017, 0 stars, 0 dependents. Pin the commit hash, vendor it into your repo, and plan a fork. Do not assume security or PHP 8 fixes — SoapClient signatures and Laravel container internals have both changed since.
• ext-soap is not optional. Many Docker images ship without it. Add docker-php-ext-install soap or apt-get install php-soap early.
• Laravel version binding. The package will resolve against old illuminate/* constraints. If you need it on Laravel 10/11, fork and widen the constraints — usually just the composer.json and possibly ServiceProvider method signatures.
• WSDL caching bites in dev. PHP caches parsed WSDLs (cache_wsdl). When you edit the WSDL and nothing changes, that’s the cause — clear it or set WSDL_CACHE_NONE in dev.
• SoapFault is not an exception hierarchy you expect. Catch \SoapFault explicitly, log getMessage() and getTrace() (the trace carries the upstream XML), and translate it to an application-level error before it leaks as a 500.
• Namespaces must match exactly. A mismatch between the WSDL targetNamespace and your binding produces looks like we got no XML document or encoding: object has no 'X' property — cryptic messages that hide a namespace typo.
• CSRF and middleware. Forgetting to exclude the SOAP route from CSRF is the single most common “it works in Postman but not from the client” bug.
• Extension points: the package’s config array and the base service/controller classes are the only seams. If you need behavior the package doesn’t offer (retries, logging, auth headers), fork and add it in your copy — don’t try to monkey-patch SoapClient.
• Modern alternative: if you’re starting fresh on Laravel 10/11, evaluate php-soap/* (php-soap/engine, php-soap/psr18-transport) or wsdltophp/packagebase first — they’re maintained and PHP 8-ready. Reach for webit/soap-api only when you’re inheriting it.