If you're asking does RavenDB (RavenHQ is just hosted RavenDB) work as persistent storage for any data system, including an API you write, of course it does. It's a document database. That's its job.
I'm not exactly sure what you're asking, unless you are asking "what is RavenDB?" If so, I recommend reading through the marketing materials and documentation at ravendb.net.
Since RavenHQ is just hosted RavenDB, it's no different than hosting a RavenDB instance directly on Amazon, Azure, or any other cloud provider.
Best I can tell is the reason you are really asking, is that you want to know if you can write a system (an API in this case) that uses cloud-hosted storage? If so, the answer is yes.
Cloud hosted storage works like local storage, with some extra latency. As long as you plan for longer response times in your design, and handle network connection failures gracefully (both of which should also be concerns even for the more common scenario of storage on a SAN or separate machines on the same LAN) then it should work just fine.
How strict you follow REST design guidelines in your custom API is completely up to you and the design of your API. It has nothing to do with your back-end storage system because you will never be exposing that directly over your API.
Regarding your mobile client design:
Yes, only requesting the data that is necessary for a client to have if they only ever need a small subset of a very large data system is a good plan.
But even though a mobile application that relies on queries over the network due to direct user actions can work, but I would discourage that exact approach for the following reasons:
- UI latency; mobile networks aren't fast, so the UI will stay blocked waiting for a response no matter how fast your API and back-end storage is. Even if that response cycle and client processing is completed in under 500ms, that's still not fast enough for a UI.
- network access is required at all times; mobile apps often need to work offline and this solution will prohibit that
- battery life and data use; if the user requests that same data over and over it would require keeping the radio on and possibly use more of the user's data plan than you should
- load; server load would be very 'bursty' depending on users usage patterns. Depending on how well designed your system is, the shape of the data, and the queries you build, timeliness of when users use it, etc. your API could get overwhelmed easily without warning
A way to fix a lot of the above issues are to use background tasks that make requests through a caching layer of your app. Then make sure your API returns responses than may be cached properly by that layer, and that it handles keeping that cache fresh.
(When implementing that caching in your API, the RavenDB, and therefore RavenHQ, caching system is very good, so you'll have no problems there, if you use it correctly. It will be more a question of "can you design your own caching out of your API correctly?")
And to enable offline usage (assuming the user can get the data once online first), you could add a 2nd layer cache that further caches to a local database, using the same caching system the first layer cache uses.
None of the above client design issues care about your back-end storage choice. It's up to the designers of the various client designs and your API design with how well those systems work together.