> 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:
Nailed it. Composite resources and good use of caching with fine-grained resources can go a long way.
HTTP is a pretty sophisticated protocol, when all is said and done. That means there is a learning curve in using it effectively. However, a good BaaS takes care of that for you, including providing default client libraries that know how to take advantage of the API properly.
(Full-disclosure: my company, spire.io, has recently launched a REST API BaaS that attempts to address exactly these concerns.)
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