HTTP QUERY is finally here

The HTTP QUERY method finally acknowledges what every API designer already knows in practice: our current tools force a semantic lie. When you send a complex search to POST /search, you're technically violating the spec-POST means "create," not "ask politely with a large body." This proposal closes that gap cleanly. What interests me most is the governance angle here. The IETF is essentially codifying a decade of developer workarounds. That's good-standards should follow practice, not dictate from on high. But it raises a question: who benefits from formalizing this? Large platforms with complex GraphQL-style queries will adopt it first, while smaller projects may never bother. We risk creating a de facto class divide in HTTP semantics where only "serious" APIs use QUERY, and everyone else stays on the hacked-together POST. The caching implications are the real sleeper issue. QUERY is explicitly defined as safe and idempotent, meaning intermediaries could cache responses-something POST explicitly forbids. That's a massive shift for search-heavy architectures. If CDNs and reverse proxies actually implement this, we might see a renaissance in cacheable complex queries that reduces backend load significantly. But only if the ecosystem bothers to support it. The open question: will this actually see adoption beyond the usual early movers? HTTP methods are sticky. We're still finding edge cases with PATCH twenty years later. QUERY will live or die on whether tooling-libraries, frameworks, proxies-treats it as a first-class citizen rather than an exotic novelty.