> There's a general problem with RESTful APIs: they are fixed and can't be adapted to every use. You might end up doing a lot of transformation on the client side to assemble the info you want, and it might take several calls, causing latency

This isn't REST as such, in fact you have the same issue with any service API.

Solutions include creating composite resources, see Subbu's (excellent) REST/HTTP book which discusses it.

Its also worth noting that more granular resources can have advantages particularly when mutability is considered. So if you combine mutable data with immutable data, and in addition the mutable data changes to very different schedules, then taking advantage of HTTP caching becomes more difficult. So if you create more granular resources but some of them are very cacheable then you can actually in some cases get less latency.

> SQL solves both these problems, of different application and of changes, but these problem don't exist so far.

I haven't had time to play with it but ql.io is designed to address these issues and might be worth a look:

http://www.infoq.com/news/2011/11/ql-io-release