I've currently got a browser talking via an "API" to the server. API is scare quoted because the API really wouldn't support another user interface very well, because it consists of every call our UI happens to need, in the form it happens to need it, and nothing else. Which could be fine. However, we are starting to have calls along the lines of "GetUserSummaryData", "GetUserHisFriendsAndHisPurchases", "GetUserAndHisPurchases", etc.
Note that on the server a more reasonable fine-grained API is written, (and the current API calls just cause the server to wire those together) it's just that what is exposed to the UI matches exactly what it needs at that particular moment.
The justification for the current approach is that going from "I need those 6 things at the moment" to "I need to make 6 calls and put the data together" has to happen somewhere, and if you do it on the server then the browser can make 1 course-grained call, vs. the alternative of either making 6 calls and taking a (significant) performance hit, or else figuring out some system of batching the 6 calls (including dealing with the issue of dependencies, possibly by having the call batching mechanism smart enough to say "the 3rd parameter of call 2 should be this part of the JSON response object from call 1" and having the server understand that).
Doing things on the server as we are does make it pretty much impossible to write another UI without making more customized views on the server to support it. But we have no reasonable current expectation that someone without access to the server would want to write another UI.
Is continuing to make really customized views on the server as the only "API" the right approach, and if not what would be better?