Good to know you're still building your own tools like back in the "old days" :)

And then everybody left, yeah, I remember this exactly.

> {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries

These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar.

> GET gets this for free because the URL is already a normalized string

It's the same principle; the order of properties matters too.

This is controlled by the (Last-Modified, If-Modified-Since) and (ETag, If-None-Match) header pairs. HTTP is stateless; it does not require any persistence. The only thing that defines kind of an optional persistence is the caching layer, for obvious reasons.

How does the origin server indicate that?

In or out of band. ie an API.

I don't think this requires so much discussion; it is a very obvious and simple addition, IMO.

How does this break rest?

It won't break GraphQL, as it uses POST. It can very much improve it if adopted: - use QUERY method when querying resources - use POST method for mutations

Because HTTP is stateless by definition, you now need to support persistence (state) on the server side whenever you want to run a slightly different query, which contradicts the preamble.

I understand the confusion around GraphQL's cached/persisted queries, but this is not the intention of HTTP.

The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc.

Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.

Its worse than alternatives because it imposes greater complexity on everybody that uses it. COBOL is also old. That also does not mean COBOL is bad, but nobody wants to write COBOL any more when there are so many better options available.

I think we're comparing two very different categories. COBOL is an application language, whereas TCP and HTTP are foundational infrastructure. Replacing a language is challenging, but replacing the infrastructure that underpins most of the Internet is orders of magnitude more complex due to the sheer number of interoperating systems.

HTTP accounts for roughly 70-80% of global web traffic, and if you narrow it to TCP-based application traffic, its dominance is closer to 95%. Comparing HTTP to COBOL is a bit like comparing trucks to bicycles...