search

blockstack-packages / blockstack-desktop-specs

Specifications for the Blockstack desktop app - a local node with a rest API and a web dashboard
MIT License
4 stars 5 forks source link

Can we get rid of the /apps section? #4

Open shea256 opened 7 years ago

shea256 commented 7 years ago

@jcnelson do you think we can get rid of the apps section and just use the /resources section for resource calls and focus on making the creation of a /stores as the equivalent of creating an app record for the user?

jcnelson commented 7 years ago

I can get behind making /resources its own top-level route.

I'm not sure I agree with making /stores a top-level collection. I see the "root" of an application's state as a user, which has a datastore, a keypair, a default session lifetime, a set of API method calls the user can make, and so on as properties. We can stop giving stores a separate :storeID, however, if you want there to be a 1-to-1 correspondence with users (in doing so, we'd also drop the methods for creating and deleting stores, since that would happen as part of creating and deleting the user).

shea256 commented 7 years ago

Oh I don't mean we should make /stores a top-level collection.

I actually meant that "Get all app accounts" (GET /users/{userID}/app) can be replaced with "Get all stores".

shea256 commented 7 years ago

We can stop giving stores a separate :storeID, however, if you want there to be a 1-to-1 correspondence with users (in doing so, we'd also drop the methods for creating and deleting stores, since that would happen as part of creating and deleting the user).

Yes I like this. Each app-user-pair would be unique and this would be reflected in the path, which has both the user ID and the app ID.