Soap Api Laravel Package

Technical Evaluation

Architecture fit. webit/soap-api is a Laravel-flavored SOAP toolkit — a package that wraps PHP's ext-soap (SoapClient/SoapServer) behind Laravel service providers, config files, and facades. Architecturally it is a thin convenience layer, not a framework. It fits only in a narrow scenario: a Laravel application that must integrate with legacy SOAP endpoints (ERP, banking, government, logistics, insurance) and where the team wants Laravel-native configuration rather than raw SoapClient instantiation. It does not fit modern greenfield architecture, event-driven services, or any stack that has already standardized on REST/JSON or gRPC.

Integration feasibility. Mechanically trivial — a Composer require plus service provider registration — but confidence is very low. The composite score of 0.06 reflects the hard signals: 0 GitHub stars, 0 dependents, last release August 2017. Zero dependents is the most damning datapoint; it means no production reference exists publicly to validate behavior, and any adoption is effectively a first-of-kind pilot. The package predates Laravel 5.5 package auto-discovery maturity, so manual provider/alias registration and a published config are likely required. PHP constraint conflicts with PHP 8.x are probable given the 2017 vintage.

Technical risk. High, concentrated in four areas:

• Abandonment. No releases in ~8 years. No security patches, no PHP 8 compatibility work, no Laravel 9/10/11/12 support. Any CVE in the underlying ext-soap or XML handling is your problem.
• Bus factor. Single author (dbojdo), no visible community, no maintainer succession.
• Compatibility decay. Composer constraints almost certainly target php: ^5.6|^7.0 and Laravel 5.x. Installing on a current LTS will require a fork and constraint rewrite.
• Hidden runtime coupling. The package inherits all ext-soap behavior — WSDL fetching, XML entity handling, blocking I/O — without adding guarantees. XXE hardening, WSDL caching, and timeout semantics are unverified.

The one positive: MIT license means forking is legally clean, and the code surface is small enough to audit in hours rather than weeks.

Key questions to resolve before any decision.

1. What PHP and Laravel versions are actually declared in composer.json, and does the code parse under PHP 8.2/8.3?
2. Is ext-soap enabled in our target runtime and container base image, or does this force an infrastructure change?
3. Does it handle WS-Security, MTOM/attachments, or custom SOAP headers — or is it plain RPC/literal only?
4. Is any team internally depending on it (undocumented), which would make this a silent-fork situation?
5. Is the actual business requirement "consume one SOAP endpoint" or "build a SOAP platform"? The former needs ~200 lines of adapter code, not a package.

Integration Approach

Stack fit. Treat this as applicable only to Laravel 5.x / PHP 5.6–7.x estate. On Laravel 10/11/12 with PHP 8.2+, it is not installable as published. The realistic decision is not "adopt the package" but "adopt the pattern, or adopt the fork."

Migration path. Three options, in order of preference:

1. Native adapter (recommended for new work). Skip the package entirely. Write a thin internal SoapGateway interface backed by PHP's SoapClient, with config-driven WSDL URLs, explicit timeouts, libxml_disable_entity_loader/XXE protections, and response mapping to DTOs. Roughly one sprint of effort, zero dependency risk, and it gives you exactly the subset of features SOAP integrations actually use.
2. Mature alternative. If the requirement is broad (WS-Security, MTOM, code generation), evaluate phpro/soap-client or laminas/laminas-soap — both actively maintained, PHP 8 compatible, and framework-agnostic so they survive a Laravel upgrade.
3. Fork and own. Only if there is existing internal code depending on this package. Vendor it into a private repository, bump PHP/Laravel constraints, add a test suite with recorded WSDL fixtures, and publish internally as ourorg/soap-api. Accept that you are now the maintainer.

Compatibility. Verify composer.json constraints first; expect to relax or rewrite them. Check for use of removed PHP functions (e.g., each(), curly-brace string offsets, create_function) that would fatal on PHP 8. Confirm the service provider still conforms to the current container contract — defer, provides, and singleton bindings have shifted over the years.

Sequencing.

1. Inventory: does anything in our portfolio already require this package transitively? (Zero dependents suggests no, but internal forks are invisible to GitHub.)
2. Spike: install in a scratch Laravel app matching our target version; record failure modes.
3. Decide: adapter vs. fork vs. alternative library.
4. Wrap behind an internal interface regardless of choice, so the SOAP transport is swappable if the upstream contract modernizes.
5. Only then wire into production config and secret management for WSDL endpoints and credentials.

Operational Impact

Maintenance. Effectively zero upstream. Once adopted, the total cost of ownership transfers to us: PHP version bumps, Laravel upgrade cycles, and any security remediation are internal work. Budget roughly a few days per major framework upgrade for validation, plus unplanned effort if a partner changes their WSDL.

Support. No vendor, no community, no documentation beyond the README. Support model is "internal subject-matter expert or nothing." If the single engineer who understands the SOAP integration leaves, the knowledge leaves with them — mitigate with recorded fixtures and contract tests.

Scaling. SOAP calls are synchronous HTTP with XML serialization on both ends. The package adds no pooling, retry, or circuit-breaking. Known scaling constraints:

• WSDL parsing cost. Fetching and parsing the WSDL on every client instantiation is expensive; cache the parsed WSDL or the client in the container as a singleton. Verify the package does this — it may not.
• Blocking I/O. Long-running partner responses will saturate PHP-FPM workers. Push non-interactive SOAP calls to queued jobs with explicit timeouts.
• Payload memory. Large XML responses are fully materialized in memory; so is DOM-based parsing. Enforce response-size ceilings.

Failure modes to instrument.

• ext-soap missing or disabled after a base-image change — fatal at boot, not at call time.
• Upstream WSDL unreachable or changed shape — silent schema drift producing null fields rather than errors.
• PHP/Laravel version drift during upgrades — Composer resolves to an incompatible tagged release.
• XXE / XML bomb exposure if entity loading is not explicitly disabled.
• Timeout-free SoapClient defaults causing hung workers.

Ramp-up. Low for the code itself — the API surface is small and a competent Laravel engineer can read it in an afternoon. High for the domain: SOAP envelope construction, WS-Security, namespace handling, and partner-specific quirks are niche skills that few engineers encounter in modern stacks. Plan for pairing and written runbooks rather than expecting self-serve onboarding. Realistic ramp-up: 1–2 days to first working call, 2–3 weeks to production-grade reliability with observability and failure handling.