Probably not? Generally there is a need for more efficient orchestration than you can achieve without per-use-case endpoints (in other words, you need to do so

Probably not? Generally there is a need for more efficient orchestration than you can achieve without per-use-case endpoints (in other words, you need to do some interdependent operations such as database access calls that depend on previous database accesses, or what have you, and those are too expensive to do due to round-trip latency over the internet, so you do them server-server). Whether the endpoint is serving JSON vs HTML, which is basically the distinction in this article, is irrelevant. I mean if you just make the same endpoints on the server that you would have made back in he HTML serving days, but instead serve JSON, and then call that an 'api', then sure, yes, but then it's a distinction without a difference, you are just moving the rendering of the data into html from the server to the client, this only a small a api, not an API as in 'the thing you use for generic 3rd party programmatic access to your features'. Also, rendering html on the client is silly and has no benefit, no matter how hip it is. It's not faster, it's not more efficient, it's much harder to test, it forces you to use a terrible language (javascript) instead of your-choice-of-any-language (which can still be javascript), it makes capturing errors harder, it dramatically increases the amount of code that has to be cross browser compatible and also has to support older browsers, and ditto all the bug stuff for performance. It's just a completely stupid idea that people are doing for no clear reason at all, generally because they have little experience and are just cargo culting whatever the cool kids with blogs are talking about.