aeden, I agree with you that the disadvantage of this approach is that you can't just repackage the client as a mobile app. However, there are two reasons why

aeden, I agree with you that the disadvantage of this approach is that you can't just repackage the client as a mobile app. However, there are two reasons why you would access the API with server side code in a web client (as opposed to a mobile one). [1] You can provide a Google friendly, static (no javascript) version of the site and all content - as opposed to a completely invisible site from an SEO perspective. [2] You can store local versions of all data that's returned from API calls. This is useful in a couple of ways. [a] It means that you need only check the API for a 'last modified' date and, if it's older than the current date, use the locally cached API call results first (if they exist). This makes the client extremely fast, since you're reading flat files locally. [b] If the API is inaccessible for some reason, the client can default to using the locally cached copies of previous API call results I built this site (backend, not the HTML/CSS/JS) the same way a while back and have been pleasantly surprised with the results - http://jacksonteece.com/ http://jacksonteece.com/