Web Api Extension Laravel Package

Product Decisions This Supports

• Build vs. buy vs. reuse for the API test-automation layer. This package sits in the "reuse" column for BDD-style JSON API acceptance testing — but with a strong negative signal. It informs the strategic call: do we standardize on Gherkin/Behat for API contract verification, or consolidate on framework-native HTTP testing (Laravel's $this->getJson() / assertJson() with PHPUnit or Pest)?
• Test tooling consolidation roadmap. Use it to frame the real question — are we maintaining more than one acceptance-test framework? This package represents the "legacy BDD" branch of that decision tree, and its abandoned status is a reason to prune rather than extend.
• Dependency intake and EOL policy. It is a textbook example of a dependency that never reached a stable release, was archived, and has zero dependents. That directly feeds rules about minimum release stability, maintenance signals, and mandatory successor plans before adoption.
• API versioning and backward-compatibility policy. The package's core premise — executable specs describing JSON API behavior — is a reusable specification pattern even though the tool is not. It supports decisions about public API contracts, deprecation windows, and what "non-breaking" means for consumers.
• Framework fit correction for the roadmap. This is a PHP/Behat 3 extension, not a Laravel package. Any roadmap item assuming Laravel-native integration (container swap, RefreshDatabase, facades, queue/event fakes) must be re-scoped; it is a black-box HTTP acceptance layer that talks to a running endpoint.
• Ecosystem gap / opportunity sizing. High "opportunity" score with zero dependents signals an unmet need and no incumbent — relevant if we are weighing investment in internal API-spec tooling rather than adopting something off the shelf.

When to Consider This Package

Only in a narrow legacy context:

• You already run a Behat 3 suite against a JSON API, the tests are green, and migration budget is unavailable this cycle.
• The API surface is internal or low-risk, and you can accept an unmaintained dependency behind a vendored/forked boundary with a documented security review and a named owner.
• You need a short-lived bridge while a replacement (framework-native HTTP tests, OpenAPI schema validation, or consumer-driven contract testing) is being built.
• You want to read it as a reference implementation for expressing API acceptance criteria — not to install it.

Look elsewhere — and this is the default:

• New projects. Archived, explicitly abandoned, never had a stable release. No security patches, no PHP-version compatibility guarantees, no support path.
• Laravel-first teams. Use Laravel's HTTP testing utilities with PHPUnit or Pest: strictly better ergonomics, maintenance, and framework alignment.
• Contract- or schema-driven validation. Evaluate OpenAPI-based validation or consumer-driven contract testing instead of prose-style Gherkin steps.
• Anyone needing an SLA, vendor accountability, or a roadmap commitment. There is none and there will not be.
• Anywhere "zero dependents" matters. Nothing else depends on it, so no community pressure keeps it working and no one has paved a migration path.

Minimum adoption bar if you must: pinned PHP runtime in CI, test-only dependency (never shipped to production), a named owner, a written exit plan with a target date, and a replacement spike already scheduled.

How to Pitch It (Stakeholders)

For executives: We evaluated behat/web-api-extension as a candidate for API acceptance testing. It is explicitly abandoned, never reached a stable release, has no dependents, and receives no updates — unbounded maintenance and security risk with no offsetting support. Recommendation: do not adopt. Its value is conceptual: it demonstrates how executable API specifications can be structured, which we can reproduce on a maintained stack. The decision required is not "should we use this" but "which maintained tool do we standardize on" — a small, time-boxed evaluation.

For engineering leads: Treat this as a rejected dependency with a useful design pattern. Do not add it to composer.json. If a legacy Behat suite exists, inventory it and scope a migration to framework-native HTTP tests or a maintained contract-testing approach. Preserve the what (API acceptance criteria as readable specs) and discard the how (this extension). Keep feature files free of extension-specific phrasing so Gherkin survives the migration.

For the product roadmap: This is a tooling-hygiene item, not a feature. Budget a short spike to pick a replacement plus a documented intake rule that excludes archived or never-stable dependencies from new work — so we stop re-litigating this class of decision.