RESTful is an oddly-specific term, so I don't see the point of changing the meaning.

Feel free to change the meaning of 'agile' to mean 'whatever' (which is how it's interpreted by 99.99% of the population), but leave things like RESTful alone.

Signed, CEO of htmx

It's weird that you would argue "people won't change" at the same time as you point out how word meanings change.

Have you forgotten how XML was all the rage not that long ago ?

Also, specific people might not change, but they do retire/die, and new generations might have different opinions...

People change organically but people can't be easily changed inentionally.

I'm not suggesting that going back to the original meaning is a bad thing, in fact more power to those who are attempting this. I'm just suggesting that instead of moving the mountain, they could just go around it.

> It's weird that you would argue "people won't change" at the same time as you point out how word meanings change.

"People won't change" does not imply "people don't change"; "I observe change" does not imply "I cause change."

Dante's Paradiso XVII.37–42 (Hollander translation): "Contingent things [...] are all depicted in the Eternal Sight, / yet are by that no more enjoined / than is a ship, moved downstream on a river's flow, / by the eyes that mirror it."

> Also, specific people might not change, but they do retire/die, and new generations might have different opinions.

Yes, that's certainly the case. "Science advances one funeral at a time." https://en.wikipedia.org/wiki/Planck%27s_principle

I think "both sides" right now are a bit wrong about the other. Content Negotiation is also an ancient part of REST. User Agent A prefers HTML and User Agent B prefers XML and User Agent C prefers JSON and all of those are still valid representations of a resource, and a good REST API can deliver some or all three as it has capability to do so. It's very much in the spirit of REST to provide HTML for your Browsers and JSON for your CLI apps and machine-to-machine calls.

This shouldn't be a "war" between "HTML is the original REST" and "JSON is what everyone means today by REST", this should be a celebration together that if these proposals pass we can do both better together. Let User Agents negotiate their content better again. It's good for JSON APIs if the Browser User Agents "catch up" to more features of REST. The JSON APIs can sometimes better specialize in the things their User Agents need/prefer if they aren't also doing all the heavy lifting for Browsers, too. It's good for the HTML APIs if they can do more of what they were originally intended to do and rely on JS less. Servers get a little more complicated again, if they are doing more Content Negotiation, but they were always that complicated before, too.

REST says "resources" it doesn't say what language those resources are described in and never has. REST means both HTML APIs and JSON APIs. (Also, XML APIs and ASN.1 APIs and Protobuf APIs and… There is no "one true" REST.)

In the near future I'll write a blog about this, but the short answer is that even though more developers use REST incorrectly than not, it's still the term that best communicates our intent to the audience we are trying to reach.

Eventually, I would like that audience to be "everyone," but for the time being, the simplest and clearest way to build on the intellectual heritage that we're referencing is to the use the term the same way they did. I benefited from Carson's refusal to let REST mean the opposite of REST, just as he benefited from Martin Fowler's usage of the term, who benefited from Leonard's Richardson's, who benefited from Roy Fielding's.