Http Method Laravel Package

Product Decisions This Supports

• Build vs. buy (and buy vs. nothing): the honest framing is that this is a ~200-line package of interface constants. The decision it actually supports is "do we add a dependency for HTTP method name constants, or use the ones our HTTP client already gives us?" For a Laravel shop, Illuminate\Http\Request and Guzzle/Symfony already ship GET/POST-style constants, so the default answer is usually "neither."
• API surface hygiene / standards alignment: when we expose or consume non-standard verbs — PURGE and BAN for Varnish/Squid invalidation, PROPFIND/MKCOL/LOCK for WebDAV, REPORT-style CalDAV flows — this package prevents magic strings from being scattered across cache-busting jobs, reverse-proxy integration code, and outbound client calls.
• Roadmap signal for caching/CDN work: if the roadmap includes Varnish, Fastly, or Squid purge endpoints, this package is a ready-made vocabulary for that workstream and a small nudge toward typed constants over 'PURGE' literals in the purge job.
• Onboarding and code review cost: it reduces the "where is this string defined?" question in reviews. Marginal, but real, and it's the main measurable benefit.
• Not a decision driver: it does not influence architecture, hosting, framework choice, or vendor selection. It should never appear on a roadmap slide as an initiative — at most as a line item inside one.

When to Consider This Package

Adopt when all of the following hold:

• We have real traffic using verbs outside the standard nine — WebDAV, CalDAV, or cache-purge (PURGE, BAN) — not just a hypothetical future need.
• The HTTP abstraction we're using at those call sites (raw Guzzle, PSR-18 client, curl wrapper) has no constants of its own, so the alternative is literal strings.
• We want one shared vocabulary across multiple packages/services in the same monorepo or org, rather than each team inventing its own.
• We're comfortable with the maintenance model: a single-maintainer package (ergebnis / @localheinz) that tracks PHP's supported-version window aggressively — it dropped PHP 7.4 in 2.3.0 and 8.0 in 2.4.0. Our PHP version must stay inside active support.

Look elsewhere or skip when:

• Laravel-first codebase. Illuminate\Http\Request::METHOD_*-style usage, Symfony's Request::METHOD_* (bundled via symfony/http-foundation), or Fig\Http\Message\RequestMethodInterface from psr/http-message utilities already covers standard verbs. Adding a second source of truth creates conflicting constants.
• Standard verbs only. GET, POST, PUT, PATCH, DELETE are already available everywhere; you'd be paying a dependency for zero informational gain.
• You need behavior, not labels. This package provides no validation, no method-to-route mapping, no HTTP verb enum with methods, no tryFrom/from semantics. Laravel 9+ backed enums let you define enum HttpMethod: string with GET = 'GET' and add isSafe(), isIdempotent(), allowsBody() in-house in about 30 lines — often the better product decision because you own the extension points.
• Dependency-governance is strict. 0 dependents and 95 stars mean thin ecosystem validation; if your policy requires a minimum adoption threshold or a named second maintainer, this fails and the in-house enum wins.

How to Pitch It (Stakeholders)

To executives (30 seconds): "A tiny, free, MIT-licensed library that gives us named constants for HTTP verbs, including the unusual ones like cache-purge and WebDAV calls. Cost is effectively zero — one Composer line, no runtime dependency beyond PHP itself, no network calls, no data handling. It's a code-quality nicety, not a strategic bet; I'd approve it only if we're actually shipping cache-purge or WebDAV endpoints, and otherwise we should just use what Laravel and Symfony already give us."

To engineering (2 minutes): "ergebnis/http-method is constants-only: a Method interface for RFC 7231/5789 verbs, a Method\WebDav aggregate for the RFC 4918/3744/4791 family, and Method\Vendor\VarnishCache / SquidCache for PURGE and BAN. No logic, no autoloading surprises. The one thing to check before merging the PR is PHP-version support — the maintainer drops EOL PHP minors in minor releases, so if we're pinned to an older runtime, Composer will fight us. It also duplicates Symfony\Component\HttpFoundation\Request::METHOD_* and the FIG RequestMethodInterface, so pick it only for the verbs those don't cover, and don't mix sources in the same file. If we'd rather not take the dependency, the fallback is a backed enum in our own app/Support namespace — same readability, one more class to maintain, plus we can attach isIdempotent() and validation helpers."

Recommendation to state plainly: low-priority, conditional adoption. Approve as a one-line addition if and only if cache-purge or WebDAV work is already on the roadmap; otherwise defer and revisit at that point.