This is exactly the use-case for Content-Type and Accept headers. The client and server negotiates what type of content they can receive/send, so if you're sending application/json as the Accept header, you can only handle application/json, if you only send text/html in the header, then only HTML. If the client understands both, you do application/json,text/html. with the order signalling preference.

Any serious framework would be able to handle this without any hiccups.

THat's how you negotiate the content type; the original question was how they have a service returning json return html. I've never heard of a framework that can arbitrarily convert data into HTML - how would that even work?

I was part of a project that when I just joined it, RESTful APIs together with fat frontend clients was becoming the hot-new-thing. The application was originally returning text/html (templates) to be injected in various part of the frontend, at request-time.

To migrate to our flashy new Angular V1 application, we added a application/json content-type that instead of returning the template, returned the data that the template used. So we could endpoint-by-endpoint migrate to the SPA we were building.

Was simply a matter of making the data required for the views a bit more advertised internally, so the controllers could instead not render the views when the content-type is json.

You could dynamically create HTML that mirrored a JSON response. You'd just have to have to walk the JSON structure and create a structure for where the key and the value from the JSON end up. Each node could just be a <div>. The ID could be a composition of the key and the parent nodes/keys so that it'd be unique. You could also stuff both values in a data-* attribute.

It wouldn't be the prettiest HTML but you could work with it via CSS and JS.

> Those exist?

For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it.

If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#id").html(val)).

Our current backends are written to support multiple generic consumers of which a web front-end is only one.

But it could

Sure but it’s extra engineering time (tiny per instance yes but multiplied over many legacy apps with no value add — not an easy business case to make just to use a html based front end library.)

Much easier to use client-side templating as suggested by the author.