What are some drawbacks of an API driven design, using jQuery JSON requests in a "Page-less" design under ASP.NET MVC 3?

Here's what I'm envisioning. Take a database (this one uses sql server 2008 spatial types/queries extensively). Build data access based on repository pattern. Setup controllers to return JSON data, based on a highly "discoverable" url scheme (/Products/TVs/Sony/27in/All, etc...).

Build a core javascript framework, in a separate file shared amongst the views so that the majority of the js code is cached on the client side.

Use the core framework methods to call those discoverable urls, pulling data via a JSON call, then utilize the MS jQuery templates to render it on the client.

Ensure these calls are cached, server side (ala output caching), as much as possible to avoi开发者_运维百科d calls to the database if possible.

Doing this, I imagine many of the repository calls that used to happen in the controller would now be occurring in the view, using the Core framework - should free up much of the load on the server, moving a bit of the work to the clients.

Having no experience with this design, what drawbacks of this design am I not foreseeing? Any good articles out there about this sort of subject? I found a bit on ZURBlog (rails based though).

---

The obvious drawback is that you're relying 100% on Javascript.

You may be leaving clients without or with limited Javascript capability in the dust.
Your site probably won't do very well in search engines, unless you also serve an HTML version.
There may be accessibility problems.

Pure Javascript sites are certainly possible, but the baseline for the web is still HTML. You may be better off starting with basic HTML pages and progressively enhance them using Javascript and JSON-only data transfer for faster page loads where available.