Should I return html or json in a ajax single page checkout

Question

I want to update a current ASP.NET webforms e-commerce site with a nice one-page checkout and I'm looking for some "best practice" on how to update the data. The page will consist of several parts: the cart, user identification, payment options, delivery options etc.

If the user changes the payment option this might result in changes in other parts of the page, like the delivery option becomes unavailable and the total cost changes.

Do I build my webservices so they return the full pre-calculated html when the user changes something on the page? Or do I return some kind of order-object in json format and update all the different parts that need updating with javascript?

The second option seem cleaner to me but is it too slow for a normal page? Or does it exist a third option?

Answer 1

I would definitely go with the second one. Return the json which is then filled in the controls from the client-side.

We use this approach in our projects. It's not slow at all, not even on our most complex pages.

Answer 2

In my view (!) it depends on the overall architecture of your app. In general it is regarded as best practice in traditional web solutions to keep the amount of logic in javascript to a minimum, and only use javascript to update the view with layout changes and such.

This is very rapidly changing as new mobile devices and HTML5 bases solutions make their entry.

• If you have a lot of logic in your javascript already it is OK to return JSON.
• If almost all of your logic is on the server you should return HTML.
• If you already have a fully rendered view and only want to update a small piece of it with new information use JSON

Most of the time I choose whatever is easiest for me to implement in the given use case.

Answer 3

99.9% of the time, JSON will be more compact than equivalent HTML: smaller payload means quicker delivery of the response. But an even more important reason is:

What if different pages want to call your webservice: one wants to display the results as a list while the other wants to display them as a table, and the third wants to put the results into a jgGrid? If your webservice returns HTML, 2 of those 3 pages can't use your service. If your webservice returns JSON, all 3 of those pages can use it easily.

What if, 2 months after deployment, your designer/site-owner wants to change the design from a table to a list? If your webservice returns JSON, your designer can make the necessary changes quickly and easily, probably affecting only 1 or 2 files in the deployed system. However, if your webservice returns HTML, you need to compile, test, and redeploy the entire webservice just to support that silly little layout change.

There may be times when returning HTML is a necessary evil (none that I can think of off-hand, but I'm sure there are some). When that happens, do yourself a favor and make sure the HTML your webservice is building can be changed without a recompile/re-deploy of the entire service. One heavy-handed but effective way to do this is using ajax to call an ASPX page.

Update: I forgot to mention: even on the slowest javascript engines (InternetExplorer), I've always found this technique (using JS to parse JSON and update the page accordingly) to perform very well.

Answer 4

You might want to check this out:

Of course each action on the catalog and the cart requires it's own Ajax request. Now if this is too simplistic then you can go for a more granular approach on the individual requests for HTML. I've found the point for breaking down the HTML requests is usually when I start breaking down the HTML into individual template objects on the server; cart template, catalog template, and checkout template.