Ok so moving right along...
I like the "resource" approach (thanks Andy) and it fits well with the single entry point w/ search style (which in turn allows for arbitrarily simple and complex environments ranging from 1 to many millions of resources). These have a category/type (e.g. server, network, storage) and content depending on that. You can of course ask for just one type or another (e.g. query "servers" but not networks or storage) and we can do a simple optimisation to bring this into line with existing APIs:
http://example.com/servers -> http://example.com/-/server
http://example.com/networks -> http://example.com/-/network
http://example.com/storage -> http://example.com/-/storage
I specifically don't like the idea of differentiating between physical and virtual resources (the whole point is that you can't, or at least don't need to, know the difference), but that's ok because I don't think it's necessary. If I'm dealing with a "server" I don't care if it's delivered as a slice, a VM or a physical machine so long as it meets my service level agreement.... this is details for the implementor and one of the areas where we need to allow them to innovate.
Ok so nouns and verbs (ignoring CRUD which is common anyway):
server:
- start
- stop
- restart
- deploy/undeploy? (comes back to persistent vs ephemeral etc.)
- clone/snapshot?
network:
- start (aka up)
- stop (aka down)
storage:
- start (aka online)
- stop (aka offline)
- snapshot?
- backup?
others?
Sam