On a related note, I recently discovered that when you use semantically styled HTML, the difference between a JSON payload and an HTML payload is almost negligible (basically, the close tags). Why not transmit in a format that the browser already understands natively?
yeah, the payload is almost zero difference, a round off error compared w/ connection latency
a lot of folks conflate AJAX w/ JSON apis, and can't easily imagine an endpoint returning partial bits of HTML that have nothing to do with a public JSON API
worse, people have been misled to believe that JSON APIs are REST-ful
Because oftentimes you’re retrieving data that will be stored in one central store and displayed / used in different ways in various components. Eg I might fetch user data and sometimes display their name, maybe another time compute their age from their birthdate, etc...
If you take a few minutes to build seperate endpoints, you'd get better performance. Both in latency/bandwidth and in system resources for your DB query.
What's the difference between building seperate code paths on the client vs. 2 server endpoints though? Very few scenarios can't afford the behind-the-scenes extra http round trip...
Because I don't want to build and maintain an API endpoint to give me an HTML blob for the users age, and another one for their full name, and another one just for their first name, and another one for figuring out what day of the year is their birthday. I want adding these features to my UI to be a client-side-only change.
Probably fine in some use cases. But another reason on top of what's already been said: Because you might be sending the data back to a non-browser client such as a mobile application.
