Se ti stai chiedendo, RavenDB (RavenHQ è appena ospitato da RavenDB) funziona come storage persistente per qualsiasi sistema di dati, inclusa un'API che scrivi, ovviamente lo fa. È un database di documenti. Questo è il suo lavoro.
Non sono esattamente sicuro di cosa stai chiedendo, a meno che tu non chieda "che cos'è RavenDB?" In tal caso, consiglio di leggere i materiali di marketing e la documentazione all'indirizzo ravendb.net .
Poiché RavenHQ è appena ospitato da RavenDB, non è diverso dall'hosting di un'istanza RavenDB direttamente su Amazon, Azure o qualsiasi altro provider di cloud.
La cosa migliore che posso dire è la ragione che stai chiedendo, è che vuoi sapere se puoi scrivere un sistema (un'API in questo caso) che utilizza l'archiviazione ospitata nel cloud? Se è così, la risposta è sì.
Lo spazio di archiviazione ospitato nel cloud funziona come l'archiviazione locale, con qualche latenza aggiuntiva. Se pianifichi tempi di risposta più lunghi nella tua progettazione e gestisci gli errori di connessione della rete con garbo (entrambi dovrebbero anche essere preoccupanti anche per lo scenario più comune di archiviazione su una SAN o macchine separate sulla stessa LAN), allora dovrebbe funzionare bene.
Riguardo a REST:
Quanto sei severo a seguire le linee guida di progettazione REST nella tua API personalizzata dipende completamente da te e dal design della tua API. Non ha nulla a che fare con il tuo sistema di storage back-end perché non lo esporrai direttamente sulla tua API.
Per quanto riguarda la progettazione del tuo client mobile:
Sì, solo richiedere i dati necessari per un client se hanno sempre bisogno di un piccolo sottoinsieme di un sistema di dati molto grande è un buon piano.
Ma anche se un'applicazione mobile che fa affidamento su query sulla rete a causa di azioni dell'utente diretto può può funzionare, ma scoraggeremo quell'approccio esatto per i seguenti motivi:
- latenza dell'interfaccia utente; le reti mobili non sono veloci, quindi l'interfaccia utente rimarrà bloccata in attesa di una risposta, indipendentemente dalla velocità dell'API e dello spazio di archiviazione di back-end. Anche se il ciclo di risposta e l'elaborazione del client sono completati in meno di 500 ms, non è ancora abbastanza veloce per un'interfaccia utente.
- l'accesso alla rete è richiesto in ogni momento; le app mobili spesso hanno bisogno di lavorare offline e questa soluzione vieterà
- durata della batteria e utilizzo dei dati; se l'utente richiede più volte lo stesso dato, richiederebbe di tenere la radio accesa e possibilmente utilizzare più del piano dati dell'utente di quanto dovrebbe
- di carico; il carico del server sarebbe molto "intenso" a seconda dei modelli di utilizzo degli utenti. A seconda del modo in cui il tuo sistema è ben progettato, della forma dei dati, delle query che crei, della tempestività del momento in cui gli utenti lo utilizzano, ecc. La tua API potrebbe essere facilmente sopraffatta senza preavviso
Un modo per risolvere molti dei problemi precedenti consiste nell'utilizzare attività in background che effettuano richieste attraverso un livello di memorizzazione nella cache della tua app. Quindi assicurati che la tua API restituisca risposte che potrebbero essere memorizzate correttamente nella cache da quel livello e che manterrà la conservazione della cache in modo corretto.
(Quando implementi quel caching nella tua API, RavenDB e quindi RavenHQ, il sistema di caching è molto buono, quindi non avrai problemi lì, se lo usi correttamente. Sarà più una questione di progetta il tuo caching dalla tua API correttamente? ")
E per abilitare l'utilizzo offline (supponendo che l'utente possa ottenere i dati una volta online), è possibile aggiungere una cache di secondo livello che memorizza le cache in un database locale, utilizzando lo stesso sistema di caching utilizzato dalla cache del primo strato.
Nessuno dei suddetti problemi di progettazione del client si preoccupa della scelta di archiviazione back-end. Spetta ai progettisti dei vari progetti client e alla progettazione dell'API con il modo in cui questi sistemi lavorano insieme.