On 03/31/2010 06:15 PM, Mark McLoughlin wrote:
> In an RPC model, we would either have 29 getter/setter methods,
or we
> would be passing around a 29-field structure, or maybe we'd have a
> generic "set key/value pair" call. None of these approaches seems very
> clean to me.
Well, with SOAP, we'd have a VM "complex type" containing the 29 fields,
so we wouldn't have 29 RPC getter/setter RPC. So, I don't see this being
a big difference between the SOAP and REST styles.
Yeah i know the complex types. But i think that there's a complexity
limit above which a document style approach starts to win over a complex
type/structure approach. Taking it to extremes, you could say that an
HTML document could be represented as a single complex type, but most
people would not think of it like that. Where the boundary lies, i think
is different for everybody.
I was more thinking of the likes of our VM control commands - start,
stop, shutdown, migrate etc. IMHO, they are essentially RPCs and don't
fit all that naturally to REST
The deltacloud way of doing this is that its instance description has a
set of action URLs which you can post to, one for each instance control
command
That seems like a good way too.
In your API, it looks like you post the command name and parameters
to a
"/vms/{id}/command" URL, right?
That's right. If you think of the command queue as the collection and
the command as an object you add to it by POSTing it, then you could say
its RESTful. But i agree it's a bit of a stretch.
I think both ways are fine, but I'm not convinced that either is
really
RESTful according to Fielding's view of the world. Maybe that doesn't
matter, though?
Eoghan had an interesting suggestion on irc. These control commands are
essentially requests for the VM to transition state, so perhaps this
makes more sense:
GET /vms/XXXX
<vm>
<id>XXXX</id>
<name>foo</id>
<state>RUNNING</state>
</vm>
PUT /vms/XXXX
<vm>
<state>SHUTDOWN</state>
</vm>
PUT /vms/XXXX
<vm>
<host>barfoo.devel.redhat.com</host>
</vm>
However, things get sticky when you think about:
- A request to shutdown might be ignored - e.g. the user might
dismiss the shutdown dialog in the guest
- A request to reboot isn't really a state transition request unless
we explicitly make REBOOTING a state
- These requests might take a long time to complete, so it might make
sense to return 202 Accepted and allow the client to poll for
completion
- The requests might accept parameters that do not belong in the
representation of a VM itself
I thought about this approach as well, but concluded it would not work
for reasons similar to the ones you describe above. If you are
requesting a state change, say, from State "Running" to "Down", then
there's not enough information in that request to execute it. It may be
the client's intention to do a hard power-off, or a shutdown instead -
both would transition from "Up" to "Down". Also as you mention some of
these transitions have parameters that do not belong to the VM. For
example, "Down" to "Running" (i.e. Start-Vm) takes up to 11
arguments.
Regards,
--
Geert Jansen, Product Marketing Manager EMEA
Red Hat S.r.L. T: +39 348 1980079
Via Antonio da Recanate 1 E: gjansen(a)redhat.com
Milan 20124, Italy
Calculate your virtualization TCO at bit.ly/7CKhUm