>>> 2. Show a deployment and its instances
>>> Each instance is listed with name and a link to the real object
>>> 3. Index of deployments
>>> 4. Delete a deployment
>>> 5. Edit a deployment - not available
>>>
>> What about other deployment actions? 'stop', 'start' (once we
can
>> re-start stopped ones), 'reboot', etc.
>
> My thought on this was that they should all just be treated as
> updates, iow, PUT the desired changes/fields in the request to
> initiate the desired action. Having a separate methods doesnt feel
> like it fits into REST properly to me. If there is disagreement here,
> I think this is a good place to iron it out, as the pattern needs to
> be established and made consistent now, before things get even more
> complex (like adding other layers of api, etc).
>
Hmm. The thing is it's not really an update. To 'stop' an instance isn't
an update to the 'state' -- the state won't change until the action is
done. We're explicitly requesting that an action occur on an instance
("please stop this now", "please start this tomorrow morning"),
which,
REST or not, doesn't feel like an update -- it's a request to do
something that might (eventually) result in an update. Surely there's a
REST-appropriate way of doing this that doesn' obscure the fact that
it's not really an update.
Scott
There might be a (nested) resource for these actions, e.g.
instanceaction. This resource would have only create action:
So requests would look like this:
POST instance/id/instanceaction?type=restart
POST instance/id/instanceaction?type=start
POST instance/id/instanceaction?type=stop
Jan