Chris,

Agreed re: "The single strongest point we want to make is that an API should be simple", and the requirement for 15-20 operations. We currently have somewhat less than that.

On Thu, Apr 16, 2009 at 11:32 AM, Chris Webb <chris.webb@elastichosts.com> wrote:
Comparison with draft API on the wiki
=====================================

The draft API on the OCCI wiki currently appears to offer nouns for servers,
storage devices, network interfaces with the ability to create, retrieve,
update and delete any noun and 6 verbs for machine control.

Our suggestion above is very similar, but more explicit and descriptive. In
particular:

 - list, info, create, destroy, set are equivalent to CRUD;

The CRUD operations map to HTTP verbs which were designed for making certain actions on a resource - I don't see that there's a need to repeat ourselves here by burning this information into the URL/request syntax. Quoting Tim again from The Sun Cloud: "If you’re going to do bits-on-the-wire, Why not use HTTP? And if you’re going to use HTTP, use it right."

Non-CRUD operations such as start, stop, restart, clone, snapshot, etc. can be exposed by "actuator" URLs, which fits nicely with HATEOAS.
 
- added drive operations: read, write, image

I've deliberately steered clear of this for the minute while we reach out to SNIA to see what they're up to in this area. Last thing we want is people having to implement a second API for storage and/or overlapping too much (but agreed we need to do some basic operations).
 
- resize operation handled by passing the new size to drive set;

Sure, retrieving the object, tinkering with it and putting it back is the best way to make such changes. I am not sold on the idea of changing "running state" variables as a mechanism for managing stage machines - the "push button" approach is cleaner and better for really simple clients.
 
- nouns for network resources (e.g. static IPs, VLANs) rather than network
   interfaces[1];

We have network resources (e.g. virtual networks) and machines can be linked to any numer of networks (including none). Operations such as setting subnet details, gateways, dhcp servers, etc. can be done by setting attributes on the network resource (but these are rare - usually you just want to instantiate a machine and connect it to storage and network resources).
 
- similar set of machine operations, assuming we want to handle stopped
   guests.

I think we'll be wanting to handle both persistent and ephemeral workloads.
 
[1] We believe that interfaces are simply one aspect of a server's
configuration, and that the nouns that matter are the objects such as static
IPs which are "owned" by a customer and hence can be configured onto the
server.

Interesting point - perhaps any static APIs available to that particular user could be exposed in the network resource itself (along with an option for DHCP if that is indeed an option).

Sam