I’m at a critical decision point in my application design. It’s an ASP.NET web application that uses REST to request information about various products. Some products have varying ProductIDs depending on their attributes/variations. For example, a user might be interested in Rogaine. A REST request about Rogain might return a response containing several variations – a 1 month supply, a 3 month supply or a 4 month supply. Each of these variations have a different ProductID, a different regular price, different sale price and a multitude of different attributes. Each one has a different set of ‘features’, different images, etc. The amount of attributes for each product can be quite a lot.
In most instances there are only a couple of product variations. Sometimes a half dozen, sometimes a dozen or two. In these instances, JSON can handle my requirements easily.
But take, for example, a dress. It might be available in a couple of dozen colors. It’s also available in 6 different sizes. You wouldn’t want to display each of these on their own page. It’s much more user friendly to display this product on a single page and present these size and color options for the user to select. Perhaps they want to order a small size in a red color.
In the example above, where there are almost 100 combinations of options. At this point, I think JSON becomes an impractical choice for me. For each unique combination, there are several links to images (each image displays the product in a different color). Each product has a list price, a regular price and a sale price, amount saved. Each has shipping attributes. Each has its own list of features which can be paragraphs of text for each product.
Ok, my point is made – this is a lot of data to be stuffing in a JSON string and there will be a delay to lookup details when a color or size is changed.
I like the way Amazon presents choices. Here is a link of such a situation:
http://www.amazon.com/American-Apparel-Jersey-Chemise-Small-Navy/dp/B003ILSHQ2/
I’ve looked in the source page and don’t see where they are storing each product’s details on the client side. If you hover each color swatch you’ll see that all the details change on the page. Price, shipping, large image, features. Virtually everything changes.
I see the “Loading…” indicators once in a while, but in most cases it’s so fast that you don’t see any signs of client/server communication.
How are they doing this without reloading the page entirely and without storing this information on the client? What technology are they using, does anyone know?
Trust me, a round trip to send another REST request each time a product variation is changed would be way too expensive. And I already have ALL of the data for every product in my first REST response. The data is not on my server or in my control and I really don’t want to save it on my server.
Since I already have all of the data, I’d like to store it so it can be used like Amazon does, but I’d like to hand it off to the client. It would be perfect to use a JSON string and in most cases, I can… but not effectively/efficiently in all.
Is there a way to index a JSON string to make it quicker for large amounts of data? Is it just too much for JSON? What other options might I have to use with JQuery/Javascript?
charlietfl answered my question best, but I couldn’t mark his responses as an answer since he didn’t post an answer, just a comment. Thanks charlietfl.