Comment by WorldMaker

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