Http Method Laravel Package

Technical Evaluation

Architecture fit. ergebnis/http-method is a pure constants library: a set of interfaces (Ergebnis\Http\Method, Ergebnis\Http\Method\WebDav, Ergebnis\Http\Method\Vendor\SquidCache, Ergebnis\Http\Method\Vendor\VarnishCache) exposing string literals for HTTP verbs. There is no runtime behavior, no service provider, no facade, no configuration. In a Laravel codebase this is architecturally inert — it can be dropped in or removed without touching container bindings, bootstrapping, or request lifecycle. The relevant question is not "does it fit the architecture" but "does it displace something Laravel already ships," and largely it does not: Laravel routes, the HTTP client (Illuminate\Http\Client), and Guzzle all accept plain strings, and Symfony's Request (which Laravel's Request extends) already provides Request::METHOD_* constants for the nine RFC 7231 verbs. The package's differentiated value is therefore narrow and specific: WebDAV verbs (PROPFIND, MKCOL, LOCK, REPORT-adjacent methods) and cache-invalidation verbs (PURGE, BAN) that Symfony and FIG do not expose.

Integration feasibility. Trivially feasible. composer require ergebnis/http-method on PHP 8.1+ (the package tracks PHP's supported-versions policy and currently supports 8.1 through 8.5); no extension requirements, no published config, no migrations. Adoption is a per-file use statement. Realistic integration surfaces are: (1) an outgoing HTTP client wrapper or SDK where verbs are passed as arguments, (2) middleware or signed-request logic that compares $request->method() against a verb, (3) tests asserting method dispatch. For a typical CRUD-oriented Laravel app, integration effort is under a day and the payoff is marginal; for an app that proxies a WebDAV store (Nextcloud, SabreDAV, SharePoint) or issues CDN purge calls, the payoff is real because those verbs are otherwise magic strings.

Technical risk. Low but non-zero, and asymmetric. The risk profile is: (a) abstraction leakage — the constants are strings, so nothing prevents a developer from writing 'GET' alongside Method::GET, defeating the purpose and creating inconsistent style; (b) constants-as-types fallacy — these are not enums, so there is no exhaustiveness checking, no match support, and no compile-time guarantee that a method reaching a client is one of the declared values. Teams that want real safety should prefer a native PHP 8.1 backed enum wrapping these values, which makes the package's interfaces a thin dependency rather than the safety mechanism itself; (c) overlap with existing constants — Symfony and FIG RequestMethodInterface already cover the common verbs, so a codebase can end up with two or three competing constant sources unless a convention is set; (d) semantic accuracy — the WebDAV interface aggregates methods from nine RFCs into one flat namespace, which is convenient but blurs which verbs a given server actually supports, so runtime capability discovery (OPTIONS/Allow header) is still required. There is no security, performance, or data-integrity risk.

Key questions.

1. Does our application actually issue any non-standard verbs today, or is this being considered for consistency alone? If the latter, reject — Symfony's Request::METHOD_* already covers it.
2. Which of the four interfaces do we need, and will we constrain ourselves to one constant source per verb across the codebase?
3. Do we need runtime method validation (rejecting arbitrary verbs before dispatch), and if so, is a constants library the right tool or should we introduce an enum plus a validator?
4. Does any downstream dependency already pull in fig/http-message-util, and if so, which source wins in our style guide?
5. Is the maintenance trajectory acceptable given a single maintainer and 95 stars?

Integration Approach

Stack fit. This is a zero-friction fit at the Composer layer and a weak fit at the framework layer. Laravel is unopinionated about where verb strings come from, so the package can be adopted in three places with no framework cooperation: (1) HTTP client call sites, e.g. Http::withMethod(Method::PURGE)->send(...) or Http::send(Method::GET, $url, $options); (2) custom request classes and form requests where method() comparisons occur; (3) test suites via $this->json(Method::POST, ...). It does not integrate with Laravel's router verb registration in any meaningful way, since Route::get()/Route::post() are named methods and route definitions are almost never built from a variable verb. Any attempt to make routing dynamic from these constants should be treated as an anti-pattern.

Migration path. Additive and reversible, which is the main argument for piloting it. Recommended sequence: (i) introduce the dependency on a single branch; (ii) pick one bounded surface — ideally an outbound integration or the WebDAV/CDN wrapper — and convert only that; (iii) add a PHP-CS-Fixer or PHPStan rule (or a simple lint/CI grep) that fails on raw verb literals within the converted directories, so the convention has teeth; (iv) only then consider broader rollout. Removal is equally cheap: composer remove plus a mechanical revert of use statements. Crucially, do not attempt a partial sweep of the whole codebase — the value comes from locality, and the cost of a half-migrated codebase (some files on Method::*, some on Request::METHOD_*, some on literals) is worse than either extreme.

Compatibility. Requires PHP 8.1+ in current releases, which is compatible with Laravel 10/11/12 projects on modern PHP; older Laravel versions pinned to PHP 7.4 or 8.0 would need the 2.3.x/2.2.x line and should be considered out of scope. The package declares no dependencies on framework or HTTP abstractions, so there is no version-conflict surface with symfony/http-foundation, guzzlehttp/guzzle, or laravel/framework — installation will not perturb the dependency graph. Namespace changed from Localheinz\Http to Ergebnis\Http at 2.0.0, so any legacy snippets found in search need that substitution if they predate the rename. Because the constants are untyped strings, no serialization, caching, or config-cache concerns apply.

Sequencing. Position this as a low-priority consistency cleanup, not a platform decision: (1) inventory non-standard verbs in the codebase — this is the go/no-go gate; (2) if the count is zero, close the ticket and standardize on Symfony's Request::METHOD_* instead; (3) if non-standard verbs exist, pilot on that single integration and add the CI guard; (4) evaluate enum wrapping as a follow-on if method validation becomes a requirement; (5) revisit broad adoption only if the pilot demonstrates measurable review-time or defect reduction.

Operational Impact

Maintenance. Near-zero ongoing maintenance by the consuming team: there is no runtime code to keep working, no config to drift, and upgrades are driven only by PHP version support. The maintenance burden sits entirely on the upstream project, which is a single-maintainer (@localheinz) repository with a consistent release cadence — the changelog shows routine PHP version enablement (8.3, 8.4, 8.5) and Dependabot-driven dev-dependency bumps. The realistic risk is abandonment, not breakage: if the maintainer stops, the package still works indefinitely because constants do not rot, but new PHP releases would eventually produce Composer constraint friction. Mitigation is trivial — the entire functional surface is ~40 string constants and can be forked or inlined into an app-level interface in under an hour. Note also the deprecation risk of the PHP support policy itself: each minor release that drops an EOL PHP version is a composer update event for consumers, so pinning to a minor range and letting Renovate/Dependabot handle bumps is preferable to a wide-open constraint.

Support. Upstream explicitly offers "limited support," which is acceptable for a constants library but should be understood as: no SLA, no paid tier beyond GitHub Sponsors, issues triaged at maintainer discretion. Internal support burden is minimal and concentrated in onboarding — new developers will not know whether to use Method::POST, Request::METHOD_POST, or 'POST' unless the convention is documented in the team's style guide and enforced in CI. That documentation is the actual deliverable of this integration, not the dependency.

Scaling. Irrelevant in the performance sense — constants compile away, add no autoload cost beyond a handful of tiny interface files, and do not participate in request hot paths. The scaling concern is organizational: the convention's value is inversely proportional to codebase entropy. In a small service with a clear boundary around one WebDAV or CDN integration, the constants are a genuine readability win. Across a large multi-team monolith with several HTTP abstraction layers already in play, adding a fourth constant source increases cognitive overhead and the probability of inconsistency. Scope accordingly.

Failure modes. (1) Silent divergence — a developer writes a raw literal next to a constant; no error occurs, the abstraction quietly erodes. Mitigation: static analysis or CI grep. (2) False confidence — the presence of Method::* constants is mistaken for method validation, when in fact arbitrary strings can still be passed to the HTTP client. Mitigation: pair with an explicit allow-list or enum if untrusted input ever influences the verb. (3) Dependency staleness — Composer constraint drift as PHP versions advance; low impact, easily fixed by fork-and-inline. (4) Version-namespace confusion — copy-pasted Localheinz\Http\Method from older articles causing autoload failures; mitigated by the mechanical rename documented in the 2.0.0 changelog. (5) No security, availability, or data-integrity failure modes exist.

Ramp-up. Effectively zero for anyone who knows PHP namespaces — the concept is self-evident from the README's usage example. The only ramp-up cost is the team convention decision (which constant source, enforced where), and that should be resolved before the dependency is merged rather than after. Realistic effort: half a day for a spike and pilot on one integration, one to two days including the CI guard and style-guide note. Given 0 dependents in the wild and thin differentiation from Symfony's existing constants, the correct default recommendation is defer: adopt only if the codebase demonstrably contains WebDAV, cache-purge, or other non-standard verbs, and in that case adopt narrowly rather than as a project-wide standard.