1

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)?

Improve this question
4
  • 5
    How do you know that the front-end is a browser and not a native application or something else?
    – JB King
    Apr 15, 2014 at 21:58
  • 2
    Congratulations! You just invented PHP (ASP, JSP, strike out whatever you don't like).
    – oakad
    Apr 16, 2014 at 6:03
  • I'm curious why you think you cant return HTML instead of JSON/XML. Thats basically the only way the web worked for its first 10 years.
    – GrandmasterB
    Apr 16, 2014 at 6:11
  • If nothing else, think of how bandwith-wasteful that is. Why would you want to keep (re)transfering parts of the UI via network (and possibly in an uncompressed-text form) when the only part that changes is the data? Why force the user to witness the complete reload of a complicated web-page in his/her browser, when you only need to change a small part of it (like the weather update in the corner of a news page) ?
    – Shivan Dragon
    Apr 16, 2014 at 7:32

4 Answers 4

Reset to default
11

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.

Improve this answer
2
  • Thanks, I checked your answer. But you can further elaborate why it's easy to 'bind' XML/JSON onto a web page?
    – user1413969
    Apr 16, 2014 at 15:59
  • There are templating systems that can do the binding for you automatically. Check out Angular.
    – Robert Harvey
    Apr 16, 2014 at 16:01
1

There are many advantages to returning JSON or XML or returning HTML:

  1. JSON (or XML) is typically more compact, so you get better performance throughout the entire system. This matters a lot on mobile.
  2. 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.
  3. 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.
  4. 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.
  5. Likewise, it's easier to test the server when your tester doesn't need to figure out what to do with the HTML.
  6. If the HTML is being generally locally, it's generally easier to style it with CSS.

I could probably come up with more.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.