Hacker News Reader

Comment by paulddraper | Hacker News Reader

SEARCH can have a request body.

Many systems limit the length of the URL, so this is significant.

If I send a request body with GET, what modern systems would even have a problem with that? Is there some caching middleware somewhere that I've never heard of or just ignored that will screw it up?

If there was a GET-with-body http verb I'd probably use it at one point or another, but I often wonder where plain GET would start blowing up if I just used it for that.

Honestly, I think rest is a mess, and that everything should just be POST with no values in the url at all.

GET with a body is pretty useless because the standard doesn’t allow the body to affect the results. So, proxies, browsers, etc. are free to ignore the body when caching results.

Quick workaround: GET /search?key=$hash(body)

Reminds me Google Maps: GET /search?pb=$protobuf_to_string.

even though most servers support it AFAIK, many clients don't. Many will even silently discard the body when sending a GET request.

So can POST. It's entirely redundant

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.

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.)

The limit of a GET request's length is at least several K on most systems I've used, so it's rarely an issue.

That's not as much as you might think.

There's a reason elasticsearch accepts POST

But what exactly is the difference between POST and SEARCH? Both include the request parameters in the body, so they would be obscured from the user. Unless they aren't, in which case it is a matter of the choices made in the implementation.

Is it implied idempotency and the lack of a confirmation dialog when the user reloads the page?

Cachability, perhaps. You cannot cache a post, but may be able to cache a search or query verb.

Reply on news.ycombinator.com