as far as I know, you do not yet provide any REST function which simply lists the keys of an application/user key-value store.
The only approach to get the list of keys is to request keys and values as a whole - which may be a bad idea with respect to devices connected over a mobile network.
The same restriction applies to the list of applications (for a given developer) or the list of registered users (for a given application)
Could these functions be added? It would be a non-breaking change in your API
I’m happy to add in a function to return only keys to the storage API - though I can’t promise I can add it quickly. In the interim, I’d suggest maintaining a list of keys in a known item. That should get you the same functionality you want at only a slight inconvenience. If you are planning to store a massive amount of data using our storage API, please let us know. It’s generally meant for small items like config settings and the like.
I might look into restricting the fields returned by calls under the /v1/app hierarchy, but given that this isn’t actually meant for anyone to use beyond the dashboard, it would be low priority. In the case of applications, a lot of extra data is returned - that’s for certain. However, this only becomes an issue for a user that has hundreds of apps. If you are planning on managing that many apps, then we definitely need to talk further.
Looking at the user data - we tried to compromise on what would be immediately useful for the dashboard vs. bandwidth. If we just returned a list of user IDs, we could save 70 bytes per user, but then how would you identify which users you wished to retrieve? At a bare minimum I think ID and email are required. At that point we’re really just talking about saving maybe 35 bytes per user record - which means that if you have 1000 users, you’ve transmitted an extra 35KB, which seems like a small savings for added API complexity.
Let me know if there’s a use case I’m not thinking of here.
I’m not thinking of “massive” amounts of data - but, since VoltCloud looks quite promising (built-in customer management + key-value-store at a reasonable price), people could start using it frequently and the overall amount of data increase continuously and permanently over time.
On the other side, just “listing” the keys of a collection should not be too complex to implement (incl. automated tests for your CI and CD) - you could copy a lot from the requests that deliver keys+values.
Keep in mind: I’m not asking for segmented output of list (to reduce bandwidth even further) or integrated filtering etc., simply the list as a whole…
I’ve logged a feature request to add flags to restrict the fields returned by getting users and getting applications. This will likely be included with filtering that allows a limited subset of users or apps to be returned. If you run into bandwidth issues prior to this being available, please let me know.
I’ve logged a separate feature request to enhance the storage plugin beyond the Web Storage API so that a list of keys can be returned.