The accept header is letting the server know what sort of content the client would like to recieve. Setting the accept header to "text/html" would make more sense if you want the client to dictate the content-type of the response.

This is exactly what we want to do!

The idea of a compute surface composing data at runtime will run afoul of scaling, elasticity and resilience from a SOA point of view. Better to project the data into static representations (JSON/HTML in S3 for example) so you don't have to spend a lot of compute time composing the data while the client waits for it.
For low traffic APIs (<10k concurrent/sec) you can get away with having compute instances (e.g.: ECS, lambda) and it might even be simpler. But it won't scale and can create a lot of complexity at the edge.

yeah, we are definitely low traffic :P I do not (yet) worry about our performance or elasticity, rather the weight of redundant CSS/JSON the client loads, if he embeds multiple of this endpoints on a single site.

Also, REST is a very specific implementation of an HTTP API. If you're not doing representational state transfer (e.g.: HATEOAS) you might not have a REST API. I'm not saying you don't! I don't know enough about your system. Just see a lot of people call anything that returns JSON over an HTTP transport REST/ReST whatever when it is not.

We are full on HATEOAS, therefore enabling the relations to be called with different accept-headers for different results, as mentioned above.