It just means you need to pass parameters to the actuator via a GET or POST request (GET comes to mind first but POST works with more/larger parameters)...

I hope I don't get a visit from the REST police for this comment, but wouldn't the GET here be frowned upon ... (??)

Meh, it doesn't matter if you push a button, poke it with a stick, kick it or use the force - the result is the same. If anyone is to be getting a visit from the REST police I guess it's me but on reviewing Tim's insightful RESTful Causistry post (and the comments) I think we're on the right track here... he talks about GET but I think either would do.

would'nt GET be prone to some kind of spider GETing all links it came across (for indexing) causing data centre havoc ? 

I don't mind this being an exception - as Peter Keene points out this is "not really an appropriately decomposed task for a REST architecture". Seth Ladd makes an interesting suggestion about modeling activities as nouns like "running" and "backing up",

So, Seth Ladds comment is essentially how I see it too. A collection of states. 

which could coexist. Elegant but complicated

... so, a server might of type "commissioned" and "currently_unavailable" classes ?? That is a nice suggestion. A implementor could choose to sub-class "currently_unavailable" with "teleporting" -  some extra information that a client could use, or just ignore.  

Roger

- let's KISS with what we have.

______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.