Let’s say that a user requests for some piece of data. Usually the data is processed via a server and then returned in XML/JSON format. Im guessing another piece of processing happens to convert it into HTML/CSS so that it could be displayed on a browser.
Why do we bother returning XML/JSON for API requests? Why can’t we just directly process whatever the user wants and just return the modified web page (HTML/CSS/JS)?
4
Because you can do many more things with real data besides display it in a web page.
HTML is just a type of output that web browsers recognize, and it’s not really useable as data in a meaningful way, because its metadata is about structure and form, not about the data itself. It also contains all sorts of things that have nothing to do with data output, such as the <input> tag.
XML and JSON, on the other hand, can be used to create dynamic HTML web pages by simply binding to it. In addition, you can create reports with it, you can analyze it with programs and algorithms, you can meaningfully put it in a database and process it further.
None of these things are really practical with HTML, since HTML is a markup language, not a data transport mechanism.
2
There are many advantages to returning JSON or XML or returning HTML:
- JSON (or XML) is typically more compact, so you get better performance throughout the entire system. This matters a lot on mobile.
- Different browsers have different bugs. If you return JSON or XML, then you only need to handle the bugs in one place, rather than on every page that generates output.
- Sometimes you have a web service where the output is for humans, other times its a remote function call. If you download JSON, then you only need a single implementation on the server to handle both web pages and API calls.
- It is easier to partition the problem, which makes it easier to have a group of people working on it. So breaking down your problem this way makes it easier for a team to develop and deploy a system.
- Likewise, it’s easier to test the server when your tester doesn’t need to figure out what to do with the HTML.
- If the HTML is being generally locally, it’s generally easier to style it with CSS.
I could probably come up with more.
HTML is used for presentation in browsers, but it adds a lot of display artifacts (like <div>, <input>, <img> tags, etc.)
XML and JSON aren’t concerned with the display … they can just send a plain representation of the data. How the user sees that data separate concern.
By separating the two, you can use the same JSON in a lot of different HTML pages.
In addition to the answers provided, there’s also the fact that in an MVC or MVP front-end, you separate the data from the view. Plus it allows the backend to be useful for multiple projects.
You can provide the same data, and have, for example, one application that displays it as a graph, one that uses it in its logic (e.g. a stock market analyser that doesn’t show the stock data but uses it to predict future prices), and one that just displays it directly to the user (perhaps prettified in some way) that can be used as an internal debugging tool for the developers.
If you had the server return HTML, only the last one would be practical. If it returned all kinds of different code depending on the client, then you’re bleeding design into function, which should be avoided.
As a general rule, presentation should never be mixed with logic. Thats the philosophy of MVC. The server deals in data and logic. It receives raw data, processes raw data, and returns raw data. It should never care what that data will look like to the user. The client’s job is to format and process the data in order to make it presentable to the user in whatever way is specified.