Now I don’t want to be a downer: but we collectively seem to have forgotten that HTML as a markup language with sufficient semantic elements, is a perfect API in itself. In fact, if we had stuck with XHTML I would’ve postulated that it would’ve been an even better API than JSON due to XPath, XQuery and XSLT.
to which another commenter replied
That was fine when (X)HTML was about semantics, but once it got used for presentation too, the contract was broken.
In turn I joined in by saying
Well, technically that’s possible with HTML, too. In addition to semantic tags we could use IDs and classes and define those as the API contract.
It’s just that nobody uses HTML like this and hence IDs and classes in particular have turned into being almost exclusively used for visual / UI aspects of a website (using CSS).
There’s nothing in principle though that keeps you from mandating that specific IDs and classes have a meaning beyond what’s represented visually and that those signifiers therefore have to both stay the same and must not be used for entities other than those they were meant for.
I still think there’s something about this idea of using the HTML representation of content on a web page or web application as an actual API to be accessed by machines and other applications rather than doing so by providing a JSON API from which HTML code is rendered. Basically, there’s no technical or conceptual limitations that prevents using HTML code as a clearly defined interface for others to consume.
It’s just we’ve grown accustomed to HTML being used as a visual design medium that defines down to the last detail how a website is to look like instead of viewing it as a data structure that defines the constraints information lives within.