Verbs specify safety/idempotency guarantees for API-blind middleware, as well as whether (if either applies) a body needs taken into account; POST is not idempotent, SEARCH/QUERY is safe, and therefore also idempotent, but differs from GET in that that guarantee is body-specific.

Might as well just say "ok now GET can have body" instead of all that noise

Won’t retroactively change things that support GET to support GET-with-body. A new verb makes it much more likely that anything that supports the verb supports the desired semantics.

(Of course, you could instead bump the HTTP version for support of GET-with-body, but given how HTTP/2 and HTTP/3 are defined in terms of HTTP/1.1, you’d need three new versions of HTTP for a change to core verb semantics. A new verb, again, is far simpler.)

From reading the article, one of the key items addressed by HTTP Search is caching. POST requests are usually not safe to cache

Is search safe to cache though?

It would definitely heavily depend on the dataset you're querying... Very little value in cached search results if you're searching through time-sensitive data such as logs or other live-datasets.

Most datasets I've searched also has a concept of permissions, so person a couldn't be served the same cached result as person b... I think search can't be cached at the http level either, its too heavily dependent on the data you're searching through so you'd have to implement it in the application anyway.

the article does make a good point though: a `get` request that supports a `body` would be nice, and thats pretty much all they're arguing for with the `search` verb.

The normal cache controls apply, so you can make it as safe as you need.