[apimade]

Why not just expose an HTML representation of the data? Why must it remain JSON, XML, CSV, Parquet, fixed length or tab delimited files, ProtoBuf, etc?

API’s should provide content in the format asked of them. CSS should be used to style that content.

This is largely solved in RFC-6838 which is about “how media types, representation and the interoperability problem is solved”. https://datatracker.ietf.org/doc/rfc6838/

Already supported by .NET Web APIs, Django, Spring, Node, Laravel, RoR, etc.

Less mature ecosystems like Golang have solutions, they’re just very much patch-work/RYO.

Or even use OpenResty or njs in Nginx, which puts the transformation in the web service layer and not the web application layer. So your data might be JSON blob, it’ll convert to HTML in real-time. Something similar can be achieved elsewhere like Apache using mod_lua etc.

I think bastardising one format (HTML), to support another format (JSON), is probably not the right move. We’ve already done that with stuff like media queries which have been abused for fingerprinting, or “has” CSS selectors for shitty layout hacks by devs who refuse to fix the underlying structure.

[_heimdall]

Rather than adding an HTML endpoint in addition to the XML or JSON, expose the data and link it to stylesheets that dynamically render the HTML client side.

That's the whole point of XSLT, ship the data and tell the browser how to transform it to HTML.

[1718627440]

Because so you can separate the data from the layout. You can e.g. return a list of strings and then the strings become the summaries of a set of details elements.

[apimade]

The description you give inherently changes the structure of the data, and JavaScript would be the best way to post-process it. CSS is about styling the structure of HTML, not structural changes to it.

Unless you have a good example, I think you’re coming at this from an “everything’s a nail if the only tool I have is a hammer”.