On Thu, May 14, 2009 at 4:24 PM, Roger Menday <roger.menday@uk.fujitsu.com>wrote:
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<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry>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 ?
Details - not if we don't include authentication information, check user agents, etc. but if we feel it necessary to keep sharp implements out of the way of the children then we can.
I don't mind this being an exception - as Peter Keene points out<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry#c1237598640.454904>this is "not really an appropriately decomposed task for a REST architecture". Seth Ladd makes an interesting suggestion<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry#c1237592841.237066>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.
A collection of states might be useful where machines are regularly in multiple states (e.g. "running" and "backing up") but I'm unconvinced there's sufficient demand/justification for the additional complexity. Most importantly, it doesn't prohibit any useful functionality that I can conceive (e.g. you can still backup and get progress via some indicator).
... 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.
Yes it (kind of) makes sense, but I'm having to exercise brain cells to understand something that should be childs play. Make the case for it (e.g. use cases that can't be satisfied without it) and we'll dig deeper. Sam